SARA-R41 series

Application development guide

Application note

SARA-R4

Abstract
This document provides detailed technology architecture and examples of how to use AT commands
with u-blox SARA-R4 series modules.

UBX-18019856 - R13
C1-Public [Link]
 SARA-R41 series - Application note

Document information
Title SARA-R41 series
Subtitle Application development guide
Document type Application note
Document number UBX-18019856
Revision and date R13 08-Jul-2022
Disclosure restriction C1-Public

Product status Corresponding content status

Functional sample Draft For functional testing. Revised and supplementary data will be published later.

In development / Objective specification Target values. Revised and supplementary data will be published later.
Prototype
Engineering sample Advance information Data based on early testing. Revised and supplementary data will be published later.

Initial production Early production information Data from product verification. Revised and supplementary data may be published later.

Mass production / Production information Document contains the final product specification.
End of life

This document applies to the following products:

Product name

SARA-R410M Except "01" product version

SARA-R412M

u-blox or third parties may hold intellectual property rights in the products, names, logos and designs included in this
document. Copying, reproduction, modification or disclosure to third parties of this document or any part thereof is only
permitted with the express written permission of u-blox.
The information contained herein is provided “as is” and u-blox assumes no liability for its use. No warranty, either express or
implied, is given, including but not limited to, with respect to the accuracy, correctness, reliability and fitness for a particular
purpose of the information. This document may be revised by u-blox at any time without notice. For the most recent
documents, visit [Link].
Copyright © u-blox AG.

UBX-18019856 - R13 Document information Page 2 of 84

C1-Public
 SARA-R41 series - Application note

Contents
Document information ................................................................................................................................ 2
Contents .......................................................................................................................................................... 3
1 Introduction ............................................................................................................................................. 8
2 LPWAN technology overview ............................................................................................................ 9
2.1 LTE Cat M1 ................................................................................................................................................... 9
2.2 NB-IoT ............................................................................................................................................................ 9
3 Application design and development........................................................................................... 10
3.1 Initial design decisions .............................................................................................................................10
3.2 Application stages ....................................................................................................................................11
3.2.1 Persistent configurations ...............................................................................................................11
3.2.2 Power on/boot/PSM exit ..................................................................................................................11
3.2.3 Network registration ........................................................................................................................11
3.2.4 IP acquisition......................................................................................................................................11
3.2.5 Core application ................................................................................................................................12
3.2.6 Power-off ............................................................................................................................................12
3.3 Application modes ....................................................................................................................................12
3.3.1 Debug / test mode ............................................................................................................................12
3.3.2 Production testing ............................................................................................................................12
3.3.3 Certification mode ............................................................................................................................12
3.3.4 Firmware update mode ...................................................................................................................12
4 Power-on/off sequence ..................................................................................................................... 13
4.1 Power-on .....................................................................................................................................................13
4.1.1 Checking SIM status at boot ..........................................................................................................13
4.2 Power-off ....................................................................................................................................................14
5 AT command response parser ........................................................................................................ 15
5.1 Unsolicited result code.............................................................................................................................15
5.2 Best practices ............................................................................................................................................16
6 Port selection ....................................................................................................................................... 17
6.1 AT interface ................................................................................................................................................17
6.1.1 Interface power saving ....................................................................................................................17
6.2 Multiplexer implementation (UART) .....................................................................................................17
6.2.1 DLCI mapping (channel support) ...................................................................................................17
6.2.2 Limitations .........................................................................................................................................18
6.3 RING indication ..........................................................................................................................................18
7 MNO profiles......................................................................................................................................... 19
7.1 Using MNO profiles ...................................................................................................................................19
7.1.1 MNO profile 0 (undefined) ...............................................................................................................20
7.1.2 MNO profile 1 (SIM ICCID select) ...................................................................................................20
7.1.3 MNO profile 100 (Standard Europe) .............................................................................................21
7.1.4 MNO profile 101 (Standard Europe No-ePCO) ...........................................................................21

UBX-18019856 - R13 Contents Page 3 of 84

C1-Public
 SARA-R41 series - Application note

7.1.5 MNO profile 102 (Standard JP) .....................................................................................................21

7.1.6 MNO profile 3 (Verizon) ...................................................................................................................21
7.1.7 MNO profile 20 (DoCoMo) ...............................................................................................................22
7.1.8 Configuration for T-Mobile US network .......................................................................................22
7.1.9 Modifiable parameters ....................................................................................................................23
7.1.10 Resetting MNO profile parameters...............................................................................................23
8 Registration with LPWAN network .............................................................................................. 24
8.1.1 Radio Access Technology (RAT) ....................................................................................................24
8.1.2 Band configuration ...........................................................................................................................24
8.1.3 Network scan and search ................................................................................................................25
8.1.4 +UMACQOSTMR timer configuration ..........................................................................................25
8.1.5 First time registration setup ..........................................................................................................26
8.1.6 Automatic and manual network registration .............................................................................27
8.1.7 MVNO users in the USA ..................................................................................................................28
8.2 Registration as PS connection ...............................................................................................................30
8.2.1 PS connections at RAT change .....................................................................................................31
8.3 Detecting the access technology ..........................................................................................................31
8.4 Mobility ........................................................................................................................................................31
8.4.1 Mobility Management procedures ................................................................................................32
8.4.2 Cell to cell (same RAT), connected mode ....................................................................................32
8.4.3 Cell to no coverage, connected mode ...........................................................................................32
8.4.4 Cell to cell (same RAT), idle mode .................................................................................................33
8.4.5 Cell to no coverage, idle mode ........................................................................................................33
8.4.6 Inter-RAT handover and change or RAT ......................................................................................33
8.5 Registration examples .............................................................................................................................34
8.5.1 LTE registration (Cat M1, NB-IoT) ................................................................................................34
8.5.2 GPRS registration (2G – SARA-R412M only) ..............................................................................35
8.5.3 SIM Issuer Identification Number detection ...............................................................................36
8.6 Roaming factors ........................................................................................................................................37
8.6.1 Higher priority PLMN scan when roaming ...................................................................................37
8.6.2 Data enable/disable roaming feature ...........................................................................................37
8.7 Booting up in offline state .......................................................................................................................38
9 Data delivery......................................................................................................................................... 39
9.1 Data planes.................................................................................................................................................39
9.2 Attach types...............................................................................................................................................39
10 PDP context / Access Point Name (APN) .................................................................................... 40
10.1 Default APNs ..............................................................................................................................................40
10.1.1 Verizon attach APN ..........................................................................................................................40
10.2 Multiple & private APNs ...........................................................................................................................40
10.3 Authentication ...........................................................................................................................................40
11 DUN/PPP ................................................................................................................................................ 41
11.1 PPP over multiple PDP contexts ............................................................................................................42

UBX-18019856 - R13 Contents Page 4 of 84

C1-Public
 SARA-R41 series - Application note

12 Monitoring module status ............................................................................................................... 43

12.1 Registration status ..................................................................................................................................43
12.2 Viewing IP address ....................................................................................................................................43
12.3 Viewing DNS address ...............................................................................................................................43
12.4 AT example .................................................................................................................................................44
13 TCP/UDP sockets ............................................................................................................................... 45
13.1 Packet switched data configuration – IPv4/IPv6 ................................................................................45
13.2 Domain name addresses .........................................................................................................................45
13.2.1 DNS caching.......................................................................................................................................45
13.3 Socket buffers ...........................................................................................................................................45
13.4 Creating a socket ......................................................................................................................................46
13.5 Closing a socket ........................................................................................................................................46
13.6 UDP ..............................................................................................................................................................46
13.6.1 Sending data ......................................................................................................................................46
13.6.2 Receiving data ...................................................................................................................................47
13.6.3 Testing ................................................................................................................................................47
13.7 TCP ...............................................................................................................................................................48
13.7.1 Connecting to server ........................................................................................................................48
13.7.2 Writing socket data ..........................................................................................................................48
13.7.3 Receiving data ...................................................................................................................................48
14 MQTT ...................................................................................................................................................... 49
14.1 Quick start based on minimal MQTT configuration ..........................................................................49
14.1.1 Restore MQTT to factory–programmed setting ........................................................................49
14.1.2 MQTT client ID specification ..........................................................................................................49
14.1.3 MQTT remote server specification ...............................................................................................49
14.1.4 MQTT connection .............................................................................................................................50
14.1.5 Additional configuration ..................................................................................................................50
14.2 Quick start based on saved NV configuration ....................................................................................50
14.2.1 Restore from saved NVM - MQTT profile ....................................................................................50
14.2.2 MQTT connection .............................................................................................................................50
14.3 Connection commands ............................................................................................................................51
14.3.1 Subscribe to MQTT topic filter ......................................................................................................51
14.3.2 Publish MQTT message to topic name ........................................................................................51
14.3.3 Read MQTT messages received ....................................................................................................51
14.3.4 Logout .................................................................................................................................................52
14.4 Profile parameters ....................................................................................................................................53
14.4.1 Login credentials ..............................................................................................................................53
14.4.2 Client ID ...............................................................................................................................................53
14.4.3 “Will Message” configuration .........................................................................................................53
14.4.4 List of MQTT profile parameters and AT commands to set them .........................................53
15 HTTP........................................................................................................................................................ 54
15.1 HTTP with server name only ...................................................................................................................54

UBX-18019856 - R13 Contents Page 5 of 84

C1-Public
 SARA-R41 series - Application note

15.2 HTTP with basic authentication ............................................................................................................54

15.3 HTTPS with SSL/TLS security certificate ...........................................................................................55
16 Secure data ........................................................................................................................................... 56
16.1 Certificate format .....................................................................................................................................56
16.2 DTLS client .................................................................................................................................................56
16.2.1 AT commands examples for DTLS client ....................................................................................56
17 Non-IP messaging............................................................................................................................... 57
18 Paging, eDRX, PSM and deep sleep mode .................................................................................. 58
18.1 eDRX ............................................................................................................................................................59
18.2 Power save mode (PSM) ..........................................................................................................................59
18.2.1 PSM with customized timer request ............................................................................................60
18.2.2 T3412 timer (Periodic TAU) ............................................................................................................61
18.2.3 T3324 timer (Active Time) ..............................................................................................................61
18.2.4 PSM modes ........................................................................................................................................61
18.2.5 PSM indication ..................................................................................................................................64
18.2.6 Host waking module from PSM .....................................................................................................64
18.2.7 PSM and roaming .............................................................................................................................65
18.2.8 PSM and LwM2M ..............................................................................................................................65
19 Application design for low power .................................................................................................. 66
19.1 Static applications ....................................................................................................................................66
19.1.1 Battery powered ................................................................................................................................66
19.1.2 Mains powered ..................................................................................................................................66
19.2 Mobile applications ...................................................................................................................................66
20 GNSS ....................................................................................................................................................... 66
20.1 Power control .............................................................................................................................................66
21 Testing ................................................................................................................................................... 67
21.1 Digital pin testing (+UTEST=10) ...........................................................................................................67
21.2 Testing with network simulators ...........................................................................................................69
22 Debugging ............................................................................................................................................. 70
22.1 Logging port ...............................................................................................................................................70
23 Migration ............................................................................................................................................... 71
23.1 SARA-G3 .....................................................................................................................................................71
23.1.1 PDP activation ...................................................................................................................................71
23.1.2 +UPSDA ..............................................................................................................................................71
24 SMS ......................................................................................................................................................... 71
24.1 SMS preferred message storage ...........................................................................................................71
25 SIM ........................................................................................................................................................... 71
25.1 Chip SIM ......................................................................................................................................................71
26 WWAN adapter.................................................................................................................................... 72
26.1 Disabling Qualcomm WWAN adapter ..................................................................................................72
27 EFS Backup & Restore ...................................................................................................................... 73
27.1 Description .................................................................................................................................................73

UBX-18019856 - R13 Contents Page 6 of 84

C1-Public
 SARA-R41 series - Application note

27.1.1 EFS backup ........................................................................................................................................74

27.1.2 EFS restore ........................................................................................................................................74
27.1.3 Creating backup after flashing FW update with delta package .............................................76
27.1.4 Automatic EFS backup performed after EasyFlash .................................................................76
27.1.5 EasyFlash and SMS storage ..........................................................................................................77
Appendix ....................................................................................................................................................... 78
A LTE Cat M1 vs NB1 ............................................................................................................................ 78
B Glossary ................................................................................................................................................. 79
C SIM issuer identification number database............................................................................... 81
Related documentation ........................................................................................................................... 83
Revision history .......................................................................................................................................... 83
Contact .......................................................................................................................................................... 84

UBX-18019856 - R13 Contents Page 7 of 84

C1-Public
 SARA-R41 series - Application note

1 Introduction
This document provides guidance for developing applications with LTE Cat M1 and NB-IoT
technologies. It includes examples of AT commands used to interface with the u-blox SARA-R4 series
modules for network connectivity.
Table 1 shows a summary of the documentation available for SARA-R4 series modules.
Document name Notes
Application integration Application development guide app note This document. Start here!
FW update app note [4] FW update procedures (uFOTA, FOAT, FOTA,
+UFWINSTALL, EasyFlash).
IoT Security-as-a-Service overview [10] IoT-as-a-Service features (local encryption, E2E
encryption, E2E symmetric KMS, Chip-to-Chip,
Zero Touch Provisioning).
GNSS implementation app note[5] GNSS interface and aiding clients. Techniques for
hybrid positioning and timing indication.
Mux implementation app note[6] Usage of multiplexer with cellular modules.
LwM2M objects and commands[7] LwM2M objects and relevant AT commands
EVK-R4 user guide [8] Starting guide for the SARA-R4 evaluation kit.
Reference documentation Data sheet [1] Use these documents as hardware integration
and AT commands API reference.
System integration manual [3]
AT commands manual [2]
Product release documents Sample Delivery Note / Information Note Delivered with every FW release.
Table 1: SARA-R4 series documentation overview

See the SARA-R4 series AT commands manual [2] for detailed AT command descriptions.

The following symbols are used to highlight important information within this document:

☞ An index finger points out key information pertaining to module integration and performance.

⚠ A warning symbol indicates actions that could negatively impact or damage the module.

UBX-18019856 - R13 Introduction Page 8 of 84

C1-Public
 SARA-R41 series - Application note

2 LPWAN technology overview

SARA-R4 series modules support both LTE Cat M1 and NB-IoT LPWAN technologies. SARA-R412M
modules also include 2G RAT for those areas which do not have LPWAN deployed, but support 2G
RAT.
Key applications using LPWAN include:
• Automotive & transportation
• Smart metering
• Smart cities
• Smart buildings
• Connected health
• Agricultural and environmental

2.1 LTE Cat M1

LTE Cat M1 is a low‑power wide‑area (LPWA) air interface that allows the connection to IoT and M2M
devices with medium data rate requirements. It enables longer battery lifecycles and extended
in‑building range, as compared to standard cellular technologies such as 2G, 3G, or LTE Cat 1.
LTE Cat M1 is part of the same 3GPP Release 13 standard that also defines Narrowband IoT (NB‑IoT
or LTE Cat NB1) - both are LPWA technologies in the licensed spectrum. With uplink speeds of
375 kb/s and downlink speeds of 300 kb/s in half duplex mode, LTE Cat M1 specifically supports IoT
applications with low to medium data rate needs. At these speeds, LTE Cat M1 can deliver remote
firmware updates over‑the‑air (FOTA) within reasonable timeframes, making it well‑suited for critical
applications running on devices that may be deployed in the field for extended periods of time.
Battery life of up to 10 years on a single charge in some use cases also contributes to lower
maintenance costs for deployed devices, even in locations where end devices may not be connected
directly to the power grid.

2.2 NB-IoT
Narrowband IoT (NB‑IoT), also known as LTE Cat NB1, is a Low Power Wide Area (LPWA) technology
that works virtually anywhere. It simply and efficiently connects devices on already established mobile
networks, and securely and reliably handles small amounts of infrequent two‑way data. And the best
is, it provides:
• Very low power consumption
• Excellent extended range in buildings and underground
• Easy deployment into existing cellular network architecture
• Network security & reliability
• Lower component cost
NB‑IoT will connect many more devices to the Internet of Things and make many new applications a
reality. It is optimized for applications that need to communicate small amounts of data over long
periods of time. Since it operates in licensed spectrum, it is secure and reliable, providing guaranteed
quality of service.

UBX-18019856 - R13 LPWAN technology overview Page 9 of 84

C1-Public
 SARA-R41 series - Application note

3 Application design and development

When designing a host application interfacing with a u-blox cellular module, consider the following
points, as depicted in Figure 1:
• Choose the module’s features that the application needs and the ones that can be disabled.
• Split the application workflow into stages.
• Design the application to work in several modes, reflecting the lifecycle steps of the product.

Before starting the design, make Consider design patterns to address

some decisions about what core features implementation.
features are to be used.

Functional Security / Power cons. Monitor

Robustness APP design
requirements LwM2M optimization Debug

Persistent
Power-on IP Power-off
configuration Registration Core application
boot acquisition PSM
(do it once)

The application shall be designed in

stages, to properly focus on each stage.

Maintenance
Production Certification Debug / test
Normal mode (FW update)
mode mode mode
mode

The application shall implement

different modes, to cover the full
lifecycle of the final solution.

Figure 1: Application design

3.1 Initial design decisions

If some features will never be used during the application lifetime, they should be disabled or properly
configured to minimize their impact on the overall performance. These decisions should be carefully
taken at the design stage because later changes could cause much effort to adapt and validate the
application.
These decisions concern:
• Usage of an LwM2M client
• Usage of security suite (if available on product type) features
• Usage of power saving
• SIM card/MNO selection
• SW/HW monitor and debug solutions
• SW/HW recovery modes
An LwM2M client is necessary to allow MNOs to contact the device and retrieve diagnostic
information; it also enables automatic periodic FOTA updates when they are available, on both MNO
and u-blox servers. Based on the target power consumption profile, the customer application can
periodically enable the client to control features, such as the periodic LwM2M registrations with the

UBX-18019856 - R13 Application design and development Page 10 of 84

C1-Public
 SARA-R41 series - Application note

server or can implement alternative or additional methods to implement FW updates when triggered,
for example by prolonged out of service conditions or by specific events.
Similar considerations hold for the security client.
Power saving features (+UPSV, PSM, eDRX) shall be configured based on the target power
consumption profile. See section 6.1.1 and 18 for more details.
The MNO profile (section 7) to be used depends on the type of application and SIM card (regional or
global roaming). If the SIM card belongs to an MNO for which the module has gained the type approval,
the MNO profile is available in the FW and shall be used.
Debug-ability can be provided via test endpoints, access to the USB interface, and in general a prolific
application log containing all AT commands strings exchanged with the module and diagnostic
information sent by the module with timing information.

3.2 Application stages

3.2.1 Persistent configurations
Some module settings via AT commands are persistent and are stored in the module Non-Volatile
Memory (NVM). Among them are: MNO profile, APN for Internet connectivity, active LTE bands.
The host application should implement a persistent configuration setting phase, performed once and
later if needed, where all AT commands related to the required settings are issued.

☞ See the SARA-R4 FW update application note [4] for persistence of settings after a FW update. If
settings are not retained, they shall be reapplied as per section 3.2.2.

3.2.2 Power on/boot/PSM exit

In general, at each boot the application should read configurations and make sure they are correct. If
not, persistent configuration can be reapplied.
Not all module configurations are persistent. Therefore, after each module boot the application should
again set these volatile configurations (e.g., +CMEE: 2, +CEREG, URC enabling of other commands).
It is very important that the application has a robust mechanism to detect when the module is ready
to communicate via AT commands at the power on. One solution, for example, is to enable the
greeting message (by means of the +CSGT AT command if available on product type); alternatively,
the host application can wait for response to “AT” command.

☞ When using PSM, at exit from low power mode the volatile settings as well as the current
communication port mode (MUX, dialup) shall be restored too.

3.2.3 Network registration

For details about the network registration stage, see section 8. This section covers the process for
the host to understand how to optimally configure itself, what it can monitor in the process, and how
to budget adequate time for networks scans.

3.2.4 IP acquisition
Once the module is registered, for LTE Cat. M1 and NB-IoT it then automatically attempts to establish
PDN connectivity and active PDP context with the network. Once PDP context is on a SIM account
that is subscribed to a data plan, IP is then available. For 2G connectivity on SARA-R412M, after
registration the PDP context must be manually activated by the host with the +CGACT AT command.

UBX-18019856 - R13 Application design and development Page 11 of 84

C1-Public
 SARA-R41 series - Application note

3.2.5 Core application

For some details and guidelines on this topic, see the various data service features in this guide and
SARA-R4 series AT commands manual [2]. The application shall handle AT commands, responses,
and unsolicited indications. For diagnostic purposes, the application should rely on status AT
commands. For robustness purposes, the application should implement embedded watchdog
procedures.

3.2.6 Power-off
When the application needs to switch off the module, be sure to follow the proper shutdown
procedures as described in the SARA-R4 series system integration manual [3].

3.3 Application modes

Typically, an application is designed based on its main use cases. This is what we call “normal mode”.
In addition, the designer should provide a way to configure the application for alternative contexts,
which can have different requirements with respect to normal mode and can help in performing other
important steps in the product lifecycle.

3.3.1 Debug / test mode

In general, an application should always output a significant log, including the AT commands it issues
and their responses, and implement monitoring logic.
If a problem occurs related to the cellular module and more information is needed, it may be necessary
to configure different verbosity levels for the host application and modules log. This may need host
application to provide an AT interface passthrough to allow access to diagnostic AT commands.
If the cellular communication is tested against a network simulator, use a suitable test SIM card
(usually provided by the network simulator manufacturer). If a solder down chip SIM is used, then
consideration should be given to having a profile that can connect to test simulators during
certification. (see section 25.1).

3.3.2 Production testing

This mode is to be used during the production tests of the end device. In this scenario usually the main
application is inactive, and AT commands can be used to properly configure the module and use its
end user testing features (see section 21).

3.3.3 Certification mode

Depending on the kind of certification, such as regulatory, conformance or for MNO type approval, the
application might be disabled, and the module externally controlled (e.g., for throughput testing).
Specific MNO tests might require the application to be running in normal mode (e.g., remote SIM
provisioning, FOTA).
If a solder down chip SIM is used, then consideration should be given to having a profile that can
connect to test simulators during certification. (see section 25.1).

3.3.4 Firmware update mode

A module’s firmware update should be implemented either over the air or tethered when necessary.
Each update strategy has its requirements and correct implementation, which should be followed to
guarantee the success of the operation. See the SARA-R4 FW update application note [4] for more
details.

UBX-18019856 - R13 Application design and development Page 12 of 84

C1-Public
 SARA-R41 series - Application note

4 Power-on/off sequence
See the SARA-R4 series system integration manual [3] which contains important information about
how to power on and off the module.

4.1 Power-on
When the SARA-R4 series modules are in the not-powered mode (i.e., the VCC module supply is not
applied), they can be switched on by a rising edge on the VCC input pins to a valid voltage level, and
then a low logic level needs to be set at the PWR_ON input pin for a valid time.
When the SARA-R4 series modules are in the power-off mode (i.e., switched off) with a valid VCC
supply applied, they can be switched on by a low pulse on the PWR_ON pin for a valid time period.
When the SARA-R4 series modules are in Power Save Mode (PSM), with a valid VCC supply still
applied, they can be switched on by a low pulse on the PWR_ON pin for a valid time period.

☞ Before the SARA-R4 series module is fully ready to operate, the host application processor should
not send any AT command over AT communication interfaces (USB, UART) of the module.

☞ The duration of the SARA-R4 series modules’ switch-on routine can vary depending on the
application / network settings and the concurrent module activities.

☞ The host application can use the +CSGT AT command to configure a known greeting text after the
module boot to tell when the AT interface is operational.

☞ The host application can use the +UGPIOC AT command to configure a GPIO pin to denote when
the AT interface is operational.

4.1.1 Checking SIM status at boot

The SIM controller SW module may need some time to load the SIM image after boot. Therefore, when
the device boots up and the AT interface becomes available, AT commands that are dependent on the
SIM may return an error result code shortly after the module boot-up. The reason is the internal SIM
controller, and its tasks may need additional time to complete initialization. This timing can vary from
one SIM type / configuration to another. Example: SIM #1 from ‘MNO #1’ may take a two hundred
milliseconds longer to load than SIM #2 from ‘MNO #2’.

☞ Both “Module Status Indication” enabled by +UGPIOC and +CSGT greeting text feature, the internal
SIM controller may not be ready after either feature indicates the module is ready with AT
command interface available.
If an error result code is returned from such a command such as +CPIN, then the host could poll the
module with the same command until it returns a response indicating the SIM controller is initialized
and ready. As an example with the +CPIN AT command and a SIM that is not PIN-locked, after module
boot-up and when the AT interface becomes available, the host would then poll every 100 ms or longer
until +CPIN: READY is returned.

UBX-18019856 - R13 Power-on/off sequence Page 13 of 84

C1-Public
 SARA-R41 series - Application note

4.2 Power-off
SARA-R4 series modules can be cleanly switched off by:
• +CPWROFF AT command
• Low pulse on the PWR_ON pin for a valid time period
• Module going into the PSM
An abrupt under-voltage shutdown occurs on SARA-R4 series modules when the VCC module supply
is removed or when a low level is applied on RESET_N pin. If this occurs, it is not possible to perform
the storing of the current parameter settings in the module’s non-volatile memory or to perform the
clean network detach.

⚠ Currently the only way to know when to remove VCC is to monitor V_INT pin and wait until it is at
0 V.
⚠ An abrupt removal of the VCC supply during SARA-R4 series modules normal operations may lead
to an unrecoverable faulty state and must be avoided.
⚠ Forcing a low level on the RESET_N pin during SARA-R4 series modules normal operations may
lead to an unrecoverable faulty state and must be avoided.

UBX-18019856 - R13 Power-on/off sequence Page 14 of 84

C1-Public
 SARA-R41 series - Application note

5 AT command response parser

This section gives some hints about how to develop an AT parser and how to handle the responses to
the AT commands and the URCs (unsolicited result code).
In this document the following naming conventions are used:
• DCE (Data Communications Equipment) or MT (Mobile Terminal) is the u-blox module
• DTE (Data Terminal Equipment) or TE (Terminal Equipment) is the terminal that sends the
command to the module
When entering AT commands, spaces are ignored. The DCE uses carriage-return line-feed pairs
(\r\n, 0x0D0A) to end lines on its output. The same termination is required on input to the DCE.
When the DCE has finished processing a command it will output a final result code (either OK or
ERROR) indicating that it is ready to accept a new command. The information text responses are
issued before the final code.

5.1 Unsolicited result code

An unsolicited result code (URC) is a string message (provided by the DCE) that is not a response to a
previous AT command. It can be output, when enabled, at any time to inform the DTE of a specific
event or status change. Examples of some URCs are as follows:
• +CEREG: <stat>[,<tac>,<ci>,<AcT>] Network registration
• +CGEV: ME PDN ACT <cid>[,<reason>[,<cid_other>]] The MT has activated a primary context
• +ULWM2MSTAT: <stat>,<percent> FOTA status update
• +UUSOCL: <socket> Socket closed

Figure 2: DTE-DCE URC flow chart

UBX-18019856 - R13 AT command response parser Page 15 of 84

C1-Public
 SARA-R41 series - Application note

5.2 Best practices

• The DTE should flush the AT channel (i.e., check if there is data waiting to be read) before sending
a new AT command.
• The DTE should handle the case of unexpected spaces or line endings.
• The DTE should handle all the URCs: it can simply ignore them (not suggested) or, better, take a
proper action.
• The DTE should know what answer is expected and should wait until it is received (i.e., final result
code only or information text response with the final result code).
• The final result code marks the end of an AT command and can be OK or ERROR. When the final
result is an error, be sure to handle it before continuing with the next AT command.
• The information text response format is command specific. The DTE will need explicit handling for
each one. It is suggested to consult the SARA-R4 series AT commands manual [2].
• It is suggested to not strictly parse information text responses but rather to check if they contain
interesting keywords and/or parameters.
• It is very useful, for debugging an application, to log all the command lines sent to the DCE and
received from it.
• Create a state machine for the AT parser (e.g., idle, waiting_response, data_mode).
• The DTE shall wait some time (the recommended value is at least 20 ms) after the reception of an
AT command final response or URC before issuing a new AT command to give the module the
opportunity to transmit the buffered URCs. Otherwise, the collision of the URCs with the
subsequent AT command is possible.

UBX-18019856 - R13 AT command response parser Page 16 of 84

C1-Public
 SARA-R41 series - Application note

6 Port selection
6.1 AT interface
SARA-R4 series modules automatically detect which interface is being used for AT commands. If the
USB interface is present by means of the VUSB_DET pin, then the USB interface is used for AT
commands. Otherwise, the UART interface is used for AT commands.
The module requires about 4 to 5 seconds to boot before the AT interface is available to the
application processor.
The GPIO pins can be configured for “Module operation status indication”, which is an indicator of
when the module has fully booted up and ready for AT commands. Issue the +UGPIOC AT command to
configure which GPIO pin is used for this indication. See the SARA-R4 series system integration
manual [3] for further details.

☞ Add USB test points to PCB design. This is critical to allow for other logging tools beyond m-center,
and to provide the ability to flash the module via EasyFlash.

6.1.1 Interface power saving

The module can go into a low power idle mode where the AT interface is turned off after 6 s of
inactivity. This can reduce the power consumption of the module between gaps in AT communication.
When in low power idle mode, the module switches to the active mode upon data reception over the
UART serial interface. The first character received in low power idle mode wakes up the system. This
extra character is not recognized as valid communication character, and the recognition of the
subsequent characters is guaranteed only after the complete system wake-up.

☞ It is recommended to use a minimal of 40 ms for waking up the AT interface when in low power idle
mode with the power saving enabled.
When in low power idle mode, the module still switches to the active mode when it is required to listen
to the paging channel of the current base station. In between the module switches back to low power
idle mode.
To enable and disable the power saving feature the host application should use the +UPSV AT
command. See the SARA-R4 series system integration manual [3] for further information about
power saving using the +UPSV AT command.

6.2 Multiplexer implementation (UART)

SARA-R4 series modules support the multiplexer as defined in the 3GPP TS 27.010 [15]. This allows
the control channel to operate on one channel and AT commands to operate on another channel.
For more details how to use the +CMUX AT command to configure the multiplexer channels, see the
SARA-R4 series system integration manual [2].

6.2.1 DLCI mapping (channel support)

SARA-R4 modules support three channels (DLCI mapping):
• Channel 0: control channel, transparent to applications
• Channel 1 – 2: AT commands / data connection
• Channel 3: GNSS tunneling data is sent to the host over this channel

UBX-18019856 - R13 Port selection Page 17 of 84

C1-Public
 SARA-R41 series - Application note

6.2.2 Limitations
The multiplexer implementation has the following limitations:
• 9600 b/s baud rate is not supported.
• When an AT command (except ATD) is sent on the channel 1, the application must wait for a
response prior to sending another AT command on any other channel and vice versa.
• For commands such as +URDFILE and +USODL, that do not return “OK” right away, the application
must wait for the command to finish execution and return the “OK” final result code prior to
sending another AT command on any other channel and vice versa.
• When ATD is sent on the channel 1 and displays “CONNECT” intermediate result code, the
application may proceed to send another AT command on any other channel and vice versa.
• When a dial-up call is active on the channel 1, the application cannot use any AT commands that
require data services on any other channel. This includes FTP, HTTP, and sockets.
• The +CMUX command cannot be used again once the multiplexer has been enabled.
• The UART baud rate cannot be changed after the multiplexer enabling, so the +IPR command
should be used to set the desired baud rate prior to using the +CMUX command.
• The software flow control (Xon/Xoff) is not supported and should be disabled.
• Multiplexer power control and wake-up mechanism (as described in the 3GPP 27.010 TS [15]) are
not supported.
• The multiplexer is supported only on the UART interface. Only one interface can be used at a time.
• If direct link mode +USODL is used on one channel, then AT commands functionality over any other
channels will not be available.
• The RI indication for an incoming SMS through the MUX MSC message is not supported.
• When the MUX is used, the URC to indicate when an incoming SMS is received is not supported.

6.3 RING indication

SARA-R4 series modules can be configured for RING pin indication via the +UGPIOC AT command. Pin
7 is configured for RING output only.

☞ When the module is in PSM, the RING indication will not be emitted.

☞ The GPIO can also be configured to note when the AT interface is ready. This can be used to detect
when the module has been woken up from PSM. See the +UGPIOC AT command description for
further information.

UBX-18019856 - R13 Port selection Page 18 of 84

C1-Public
 SARA-R41 series - Application note

7 MNO profiles
Mobile Network Operator (MNO) profiles provides with a powerful and flexible method to configure the
SARA-R4 module to seamlessly work with the selected operator.
Using the MNO profiles the SARA-R4 module is dynamically configured to use the proper bands,
RATs, power saving parameters, eDRX parameters and the operator-dependent protocol stack
settings needed to operate on the selected network in full compliance with the operator requirements.
With the MNO profiles, customer application is not required to configure the module using complex
and/or network-dependent parameters, but benefits from a “out of the box” solution that provides
seamless connectivity while abstracting the complexity of managing individual network
configurations. MNO profiles are decoupled from the module firmware and therefore can be
dynamically updated (for example in case of network parameters change) – even after deployment –
without the need of updating the modem firmware.
In addition, generic MNO profiles are provided to provide full module configurability to the
applications.
Use the +UMNOPROF AT command to select a profile for the network operator.
SARA-R4 modules certified for specific operators should use the corresponding MNO profile to meet
operator requirements for which it was certified. For example, if a SARA-R410M-52B is certified for
the AT&T network the host application should set the +UMNOPROF to the corresponding AT&T profile.

☞ To view the list of available MNO profiles, use the +UMNOPROF test command.

☞ Use AT+UMNOPROF=,1 to enable the version text of the profile when they are listed using the above
command. For more details, see the SARA-R4 series firmware update application note [4].

⚠ For use on other networks that are not listed, if it is available on the product, use the MNO profile
100 (standard European) and configure RATs and bands accordingly.

This section covers some MNO profiles that are made available on certain products. For the list of
MNO profiles available on each of the product types and their settings for that product, see the
SARA-R4 series AT commands manual [2].

7.1 Using MNO profiles

To configure the module to use an MNO profile the host must first select the profile using the ID
number and then reset the module (with the +CFUN AT command). When the module reboots it will
configure itself to use the parameters specified by the MNO.
The factory-programmed configuration or initial default state of the module of the MNO profile
depends on the SARA-R4 product version:
• SARA-R4 “02” / “52” product versions: profile 0
• SARA-R4 “63” product version: profile 28 (SoftBank)
• SARA-R4 “73” product version: profile 39 (SK Telecom)
• SARA-R4 “83” product version: profile 4 (Telstra)

☞ The host application must specify an MNO profile.

☞ Reboot the module with the AT+CFUN=15 command to make the MNO profile active.

UBX-18019856 - R13 MNO profiles Page 19 of 84

C1-Public
 SARA-R41 series - Application note

7.1.1 MNO profile 0 (undefined)

It is strongly recommended to configure the module to the applicable MNO profile, RAT, and LTE
bands intended for the application device and within regulatory compliance. The module is not
intended to be used in the +UMNOPROF: 0 configuration on a real network. It is recommended to use
this undefined profile during production or laboratory testing only. With this profile LwM2M is
disabled.
From a regulatory perspective, MNO profiles do not affect the low-level RF performance of the module.
Some profiles, however, may enable features not available on a simulated network which are known
to interfere with laboratory measurements. By setting to the +UMNOPROF: 0 configuration, unexpected
behavior during RF testing is reduced.

7.1.2 MNO profile 1 (SIM ICCID select)

☞ MNO profile 1 uses a pre-loaded issuer identifier number (IIN) database to select the MNO profile.
If the SIM IIN is not in the database, it will not be recognized.
The MNO profile 1 will read the SIM ICCID number and use the IIN information to select the MNO
profile. If the SIM ICCID is not recognized as belonging to an existing MNO profile, then the previous
setting will be used.

☞ The previous setting may also include MNO profile 0. Use AT+UMNOPROF=1 to enable SIM ICCID
select mode.
See Appendix C for IIN values stored in lookup database.
The AT+UMNOPROF=1 behavior differs between products. For more details, see the three tables below.
SARA-R410M-02B-00,SARA-R410M-52B-00,SARA-R412M-02B-00, SARA-R412M-02B-01,
SARA-R412M-02B-02
Command Response Description
AT+UMNOPROF=1 OK Select the SIM ICCID select mode.
Insert or switch to different SIM.
AT+CFUN=15 OK Reset the device.
The device will reboot twice.
AT+UMNOPROF? +UMNOPROF: 2 Upon the module boot-up check the carrier profile that
OK has been set.

SARA-R410M-02B-01, SARA-R410M-52B-01, SARA-R410M-02B-02, SARA-R410M-52B-02,

SARA-R410M-02B-03, SARA-R412M-02B-03, SARA-R410M-02B-04, SARA-R412M-02B-04
Command Response Description
AT+UMNOPROF=1 OK Select the SIM ICCID select mode.
Insert or switch to different SIM.
AT+CFUN=15 OK Reset the device.
AT+UMNOPROF? +UMNOPROF: 0 Upon the module boot-up ICCID select mode is exercised.
OK
AT+CFUN=15 OK Reset the device to activate the auto selected profile.
AT+UMNOPROF? +UMNOPROF: 3 Upon the module boot-up check the carrier profile that
OK has been set.

UBX-18019856 - R13 MNO profiles Page 20 of 84

C1-Public
 SARA-R41 series - Application note

SARA-R4 “63” / “73” / “83” product versions

Command Response Description
AT+UMNOPROF=1 OK Select SIM ICCID select mode.
Insert or switch to different SIM.
AT+CFUN=15 OK Reset the device.
AT+UMNOPROF? +UMNOPROF: 1,0 Upon the module boot-up ICCID select mode is exercised.
OK
AT+CFUN=15 OK Reset the device to activate the auto selected profile.
AT+UMNOPROF? +UMNOPROF: 1,4 Upon boot-up check the carrier profile that has been set.
OK

7.1.3 MNO profile 100 (Standard Europe)

The MNO profile 100 should be used as the basis for all other MNOs in Europe outside of Vodafone
and Deutsche Telekom. However, there may be changes that need to be applied to the module for
proper operation with any given MNO such as attach type, RAT preference, band selection, etc. Please
consult with the preferred network provider.
If the device is attaching to a network operator (even outside of Europe) that is not listed in the MNO
profile list, MNO profile 100 should be used as a generic and configurable profile
Also, it is recommended to use this profile for mobile virtual network operator (MVNO) and/or roaming
SIMs. For example, in the USA region, for a roaming SIM that is not branded and issued directly from
AT&T use this profile instead of MNO profile named specifically “AT&T” such as MNO 2 or 198.

7.1.4 MNO profile 101 (Standard Europe No-ePCO)

This profile is similar to MNO profile 100. The only difference is an extended Protocol Configuration
options (ePCO) container is not used in NAS (Network Access Stratum) messaging when attaching to
an LTE network. It has been found that some NB1 mobile operators do not support ePCO container.
Therefore, if ePCO is used in the attach for such a network, this will result in lack of DNS capabilities.
For NB1 networks that are known to not support ePCO, this profile is recommended.
The host may need to reconfigure this MNO profile for the intended network with parameters such as
attach type, RAT preference, band selection, etc.
The Standard Europe No-ePCO profile is not supported by SARA-R4 “52” / “63” / “73” product
versions.

7.1.5 MNO profile 102 (Standard JP)

On SARA-R410M-63B-01, this MNO 102 Standard JP profile is intended for MVNO and/or roaming
SIMs for Japanese networks. The concept is similar to the standard Europe profile, but specific to the
Japan market on the products that feature this profile. Use this profile instead of using dedicated
carrier MNO profiles intended for matching carrier SIMs, such as for SoftBank or DoCoMo.
The host may need to reconfigure this MNO profile for the intended network with parameters such as
attach type, RAT preference, band selection, etc.

7.1.6 MNO profile 3 (Verizon)

MNO profile 3 is configured for Verizon Wireless. This will clear the attach EPS bearer APN string and
automatically define all the Verizon APNs in +CGDCONT context identifier list. For more details, see
section 10.1.

UBX-18019856 - R13 MNO profiles Page 21 of 84

C1-Public
 SARA-R41 series - Application note

7.1.7 MNO profile 20 (DoCoMo)

On SARA-R410M-63B-01, on Docomo’s network with this profile, the LwM2M client will connect to
Docomo’s LwM2M server for DM (Device management) services. This includes FOTA FW update
capability, amongst others that DoCoMo may exercise between OMA object IDs from 0 to 7.
On SARA-R410M-63B-01 the default LwM2M binding mode on the module’s client is different than
the LwM2M server and this mismatch prevents the client to register with the server. DoCoMo requires
LwM2M DM to be enabled, therefore the host application needs to modify the DoCoMo DM server
binding mode with the following procedure outlined below.

Changing binding mode with Docomo LwM2M DM server when <MNO>=20 profile used
Command Response Description
AT+ULWM2MSTAT=1 OK Enable the LwM2M URCs.
AT+CFUN=15 OK Perform a reset. This is to catch any
URCs from LwM2M client from boot-up.
+ULWM2MSTAT: 1, 123, 2 Wait for notification of LwM2M
bootstrap completed.
AT+ULWM2MWRITE="{\"bn\":\"/1/0/\" OK Modify the DoCoMo server instance by
,\"e\":[{\"n\":\"7\",\"sv\":\"UQ\ setting binding mode to "UQ”.
"}]}"
AT+ULWM2MSTAT=0 OK As an option, the host can perform this
step to disable LwM2M URCs

☞ Per MNO requirements, it is required by DoCoMo when using SARA-R410M-63B-01 with MNO 20
to change the binding mode as described in the above to support DoCoMo DM server.

☞ LwM2M is disabled by default for the DoCoMo profile. If a user should subscribe to DoCoMo
LwM2M services, then DoCoMo will permit the LwM2M client to be turned on via AT+ULWM2M=4.
If the LwM2M service subscription is later terminated, cancelled, or discontinued, then the host
must disable the LwM2M client with AT+ULWM2M=3 per DoCoMo’s requirement.

7.1.8 Configuration for T-Mobile US network

☞ This section is only applicable to modules that do not support the T-Mobile US MNO profile
(+UMNOPROF: 5) but are certified for T-Mobile US network operations.
For end devices using a T-Mobile US SIM and that will certify with the operator, the configuration
procedure should be performed:
• Set MNO profile to Sprint (+UMNOPROF: 8).
• Configure the active bands to only band 2 and 12.
Configuring profile for T-Mobile US
Command Response Description
AT+UMNOPROF=? 0: SW default Optionally read allowed MNO profiles
1: SIM ICCID select
2: ATT
3: Verizon
4: Telstra
8: Sprint
19: Vodafone
21: TELUS

UBX-18019856 - R13 MNO profiles Page 22 of 84

C1-Public
 SARA-R41 series - Application note

Command Response Description

31: DT
33: VIVO
43: ROGERS
44: Claro Brasil
45: TIM Brasil
46: Orange France
100: Standard Europe
101: Standard Europe No-ePCO
198: AT&T Profile 2-4-12
206: FN ATT
OK
AT+UMNOPROF=8 OK Select Sprint MNO profile.
AT+CFUN=15 OK Reboot the module.
AT+UMNOPROF? +UMNOPROF: 8 Check the active MNO profile by the
OK +UMNOPROF read command..
AT+CFUN=0 OK
AT+UBANDMASK? +UBANDMASK: 0,16779274,1,16779274 Read default band mask
OK
AT+UBANDMASK=0,2050 Configure the LTE-M band mask to
enable only band 2 and 12
AT+CFUN=15 Reboot the module.
AT+UBANDMASK? +UBANDMASK: 0,2050,1,16779274 Check band mask is set correctly
OK

7.1.9 Modifiable parameters

MNO profiles configure the module with a set of parameters. Depending on the MNO profile, some of
these parameters can be overridden by using AT commands. Below is a list of AT commands which
can be used to set the module configuration after it has turned on.
• +UBANDMASK Band mask
• +URAT RAT priority list
• +CPSMS PSM timer values (T3324, T3412)
• +CEDRXS eDRX configuration
• +CGDCONT APN and PDP context
• +USCVDOMAIN Attach type: EPS only or combined attach
If the host changes any of these parameters, they will be retained after a module reset.
To see what parameter can be reconfigured for a given MNO profile, see SARA-R4 series AT
commands manual [2].

7.1.10 Resetting MNO profile parameters

To reset back to the MNO profile parameter values the host will need to move to another MNO profile
and then back again. Sending the same AT+UMNOPROF AT command will also not reset the changed
parameters. Each time the host must reboot the module.

UBX-18019856 - R13 MNO profiles Page 23 of 84

C1-Public
 SARA-R41 series - Application note

8 Registration with LPWAN network

At the power-on the module reads the information in the currently selected MNO profile. It will use
this information to configure which bands to scan, the radio access technology to use and other
attach parameters.
Once the module has found a cell it can camp on, it will start the registration process. If the SIM card
has a valid account, it will start the provisioning process automatically. The +CPIN AT command may
need to be entered for the device to start the provisioning process.

☞ Use +CNUM and +CGDCONT AT read commands to view the MDN number and APN assigned after
the module has registered on the network. (Not all network operators assign an MDN.)

☞ Use the +COPS AT read command to view the network information, and the +CESQ AT command
to check the signal conditions.

☞ If the SIM card is locked with a PIN, then the LwM2M client may not be properly configured, since
it will not be able to retrieve SIM information. This is most relevant in Verizon MNO profile
(+UMNOPROF: 3) where the SIM information is used to build the DUT endpoint name. It is then
recommended to insert the SIM PIN, if enabled, within 10 s of the module boot.

⚠ Configure the module to the desired MNO profile for it to function properly on the network it is
intended to be used on. Set the MNO profile on the very first use, or after flashing new firmware.
⚠ Applications shall select a proper MNO profile and not leave the factory-programmed undefined
profile.

8.1.1 Radio Access Technology (RAT)

Use the +URAT AT command to select the order of preference of networks the module should try.
Each MNO profile has a defined RAT search priority.
The module will search all the bands configured in the +UBANDMASK list on each RAT before moving on
to the next RAT in the priority list. This means if only 2G services are available and the module is
configured for all bands in LTE Cat M1 and NB-IoT, it may take many minutes to finally select a 2G
network.

8.1.2 Band configuration

SARA-R4 series modules can scan several bands to find a network to attach to. The host application
can limit the scanning to specific bands to shorten the time to find a network.
Use the +UBANDMASK AT command to specify these bands as an 8 byte bitmask. Each band is enabled
by summing the band values together, where each band value is represented by 2(band-1). For example:

☞ Each MNO profile will define a set of bands to scan on.

☞ LTE Cat M1 and NB1 both have individual band masks, which need to be configured separately.
AT+UBANDMASK=0,<band mask> for LTE Cat M1, AT+UBANDMASK=1,<band mask> for NB1.

UBX-18019856 - R13 Registration with LPWAN network Page 24 of 84

C1-Public
 SARA-R41 series - Application note

8.1.3 Network scan and search

SARA-R4 series modules will scan each band configured for each RAT selected. By reducing the
number of bands and selecting only one RAT, the module may attach to a network quicker than if all
bands are configured.
SARA-R4 series modules perform a network search and selection according to 3GPP TS 23.122. The
module tracks the PLMN / band information of scanned cells in addition to the PCI (Physical Cell ID) of
the cell it attaches to in a local acquisition table, which it looks up to when there is a loss of signal.
Upon start-up, the module will first look at this acquisition table for a previously camped cell to try and
attach to it. If the acquisition list is empty or if none of the cells in the table are available to be seen,
the module will restart scanning the RATs (in order of priority) and bands (in an increasing numerical
order) that have been configured in the MNO profile.
The +URAT and +UBANDMASK [if available to reconfigure in the active MNO profile] AT commands
contain the RAT preference and LTE bands, respectively. In general, the band scan process for LTE
Cat. M1 (1.4 MHz at a time) bands takes just a few seconds in comparison to NB1 which can take
about 2 minutes per band (100 kHz at a time and this is per design).
Because NB-IoT allows for cells to be found with much higher dynamic range, the scan time in NB-IoT
is much longer than LTE Cat M1. If the application has configured NB-IoT as well a LTE Cat M1, but
there are no NB-IoT networks the module may take a couple minutes per band to complete the NB-IoT
scanning before re-trying the LTE Cat M1 RAT scan.

8.1.4 +UMACQOSTMR timer configuration

☞ The +UMACQOSTMR AT command is supported by SARA-R4 “02” product versions except for
SARA-R410M-02B-00, SARA-R410M-02B-01, SARA-R410M-02B-02, SARA-R412M-02B-00, and
SARA-R412M-02B-01.
The +UMACQOSTMR AT command allows configuration of a MAC layer timer that acts as an optional
and additional mechanism that can be enabled to ensure LTE network local RRC release and return to
idle after prolonged RX and TX inactivity of the radio channel. It is referred to being an “additional
back-up mechanism”, since the RRC procedure would normally handle the local RRC release. However,
if there is a rare instance that it does not release timely with a network, this mechanism provides
added reliability. An optimal and timely local RRC release is important to ensure the proper handling
of any potential inbound network pages.
Timer recommendations:
• If a timer is not enabled by default in MNO profile, enable the timer for LTE-M via +UMACQOSTMR
AT command.
• Use an optimal timer value of 90 s.
For NB-IoT there is no recommendation to have it enabled.
Check in the appendix of the SARA-R4 series AT commands manual [2] for details on the default
+UMACQOSTMR settings in the Mobile Network Operator profiles section.
Example sequence to configure the +UMACQOSTMR AT command setting:
Command Response Description
AT+UMACQOSTMR? +UMACQOSTMR: 35,-1 Read +UMACQOSTMR timer
OK configuration.
AT+UMACQOSTMR=90 OK Set timer value to 90 s for LTE Cat M1.
AT+CFUN=15 OK Reset the device to make persistent
setting effective.

UBX-18019856 - R13 Registration with LPWAN network Page 25 of 84

C1-Public
 SARA-R41 series - Application note

Command Response Description

AT+UMACQOSTMR? +UMACQOSTMR: 90,0 Read UMACQOSTMR timer
OK configuration to confirm change.

When using network simulators, to perform certain types of measurements there may be a need to
stay in local RRC connected state. See section 21.2 for details for guidance to disable the timer in
such situations.

8.1.5 First time registration setup

It is important to set the operator profile first because this operation will configure the default RAT
and band mask for that corresponding profile. If applied after +URAT or +UBANDMASK, it will override any
past configuration the host application has made.

☞ The host application should always set the MNO profile.

☞ For standard European operation when the MNO is not listed, use MNO profile 100.
After setting the MNO profile the application may modify the Radio Access Technology priority and
band mask.
Possible reason for setting +URAT may include:
• Radio Access Technology is not deployed by the network carrier yet in the area device is intended
to run on. Therefore, only enabling the desired RAT will reduce the scan time when the device is
searching for the network.
Possible reason for setting +UBANDMASK may include:
• Band(s) is not deployed by the carrier yet in the area device is intended to run.
• The device is an area where it is interested in running on specific bands only.
• Reducing the number of bands will reduce the scan time when the device is searching for the
network.
Below is an example of going through the above steps in configuring the SARA-R4 module:
Step #1: Set the profile to standard Europe
Command Response Description
AT+UMNOPROF=100 OK Set the carrier profile to standard Europe.
AT+CFUN=15 OK Reset the device to make setting effective.
AT+UMNOPROF? +UMNOPROF: 100 Upon boot-up check that the carrier profile is set
OK correctly.

Step #2: Set the +URAT to LTE Cat M1 only

Command Response Description
AT+COPS=2 OK Deregister from the network before setting RAT.
☞ It is possible to issue AT+CFUN=0 or
AT+CFUN=4 instead of the AT+COPS=2
command.
AT+URAT=7 OK Set the RAT to LTE Cat M1 only.
AT+CFUN=15 OK Reset the device to make setting effective.
AT+URAT? +URAT: 7 Check that RAT is set to LTE Cat M1 only, by the
OK +UART read command .

UBX-18019856 - R13 Registration with LPWAN network Page 26 of 84

C1-Public
 SARA-R41 series - Application note

Step #3: Set +UBANDMASK

Command Response Description
AT+UBANDMASK=0,2 OK Set LTE Cat M1 band mask to band 2 only.
AT+CFUN=15 OK Reset the device to make setting effective.
AT+UBANDMASK? +UBANDMASK: 0,2,1,2074 Upon reboot check the LTE-M band mask is correctly
OK set to band 2 only.

The above two steps can be combined as such:

Command Response Description
AT+COPS=2 OK Deregister with the network.
It is possible to issue AT+CFUN=0 or AT+CFUN=4
instead of the AT+COPS=2 command.
AT+UMNOPROF=100 OK Set the carrier profile to standard Europe.
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+URAT=7 OK Set the RAT to LTE Cat M1 only.
AT+UBANDMASK=0,2 OK Set LTE-M band mask to band 2 only.
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+UMNOPROF? +UMNOPROF: 100 Upon boot-up check that the carrier profile is set
OK correctly.
AT+URAT? +URAT: 7 Check the +URAT status that RAT is set to LTE Cat
OK M1 only.
AT+UBANDMASK? +UBANDMASK: 0,2,1,2074 Upon reboot check the LTE-M band mask is correctly
OK set to band 2 only.

For more details on the AT commands used in the example, see SARA-R4 series AT commands
manual [2].

8.1.6 Automatic and manual network registration

There are two modes for PLMN selection.
Automatic:
The AT+COPS=0 command performs an auto scan on the capable RATs of the module and search
PLMNs on the module. The module will choose the best cell and PLMN that allows the subscriber (SIM
card) to get on to which can take a while at times. The module will initially try looking for a HPPLMN
(High priority) and if not found, the module will look for a roaming PLMN cell as a lower preference.
When the auto selection is set, the module will time and again get into a scanning mode and it will
keep trying to find a HPPLMN. The module will try all possible operator networks if the band being
used by them has been configured on the module.
The module always prefers to be in non-roaming (with auto cops) cell. When the +URAT AT command
is configured to 7, 8, 9 (on SARA-R412M) assuming operators are allowing the subscriber to Roam
and if the AT+COPS=0 command is issued, the module will try looking for HPPLMN in LTE Cat. M1
followed by NB1 and then try 2G RAT. The module could end up camping on 2G (even if it is roaming)
as the network allows it to camp.
If the module lands on a roaming cell, the background PLMN scans can take the module out from the
PSM and result in higher average power consumption. In addition, even if the module is in connected
mode, these PLMN scans will pre-emptively abort the connection and force a local channel release.
This will occur per 3GPP requirements of 2 minutes after the first registration in roaming on a VPLMN
at power on if the SIM card lists a higher priority PLMN with the same MCC of the current VPLMN in
the Operator or User Preferred PLMN list file. Successive PLMN scan will be periodically triggered
based on the values of the HPPLMN (High Priority) timer in the SIM file. Refer to the section 8.6.1.

UBX-18019856 - R13 Registration with LPWAN network Page 27 of 84

C1-Public
 SARA-R41 series - Application note

☞ The AT+COPS=2/AT+COPS=0 registration cycle in roaming might trigger the full PLMN scan,
while the AT+CFUN=0/AT+CFUN=1 cycle will select the last registered PLMN without additional
scans.
Manual:
The AT+COPS=1,2,”PLMN”,<Act> command will do a specific manual PLMN search, the module will
try to attach to a cell and even if it is roaming, it will still get on to it if the PLMN matches. With the
manual AT+COPS=1, the module will reduce the scanning process as well. For e.g., if the user wants
to attach to a certain carrier like AT&T on LTE Cat. M1, a AT+COPS=1,2,“310410”,7 command may
be issued. The manual network selection will work faster and save battery by not waiting for module
do a complete scan and decide to get onto a network.
Issuing AT+UMNOPROF=100 and AT+URAT=7,8,9 (on SARA-R412M), the module will scan LTE Cat.
M1 (as first preferred), NB1 (as second preferred) and 2G (as third preferred). The module will get on
to LTE Cat. M1 first if available and only if there is no LTE Cat. M1signal, the module will search for
NB1 and only if there is no NB1 it will try to register on 2G RAT. If the module got on to a 2G network,
it would look out for LTE Cat. M1 once again only when it loses registration on 2G RAT and switch over
to LTE Cat. M1 while it is available or right away when 2G signal is lost.

☞ 2G networks in the USA have been decommissioned by some operators and may be completely
shut down by remaining operators by the end of 2022.
Some networks might reject the attach if the type of attach is not allowed. The +USVCDOMAIN AT
command can be set to CS+PS and the module can register to a valid network A (as supported by the
SIM), but then if the module loses network A and later finds a valid network B (as supported by the
SIM) that supports PS only, the module might not be able to attach to this network B. It is good to
check what type of attach is preferred by a network.

8.1.7 MVNO users in the USA

In the USA, major carriers like AT&T and Verizon have a nationwide coverage for LTE Cat M1. A factor
to consider when using a mobile virtual network operator (MVNO) SIM is that multiple carriers will
show up with AT+COPS=? If the selected MNO profile configuration can support the type of
networks/operators it can attach to.
Command Response Description
AT+COPS=? +COPS: (2,"AT&T","AT&T","310410",7), • 310410 is AT&T.
(1,"313 100","313 100","313100",7), • 313100 is AT&T’s FirstNet.
(1,"310 260","310 260","310260",0),
• 310260 is T-Mobile US.
(0,1,2,3,4),(0,1,2)
• 311480 is Verizon.
OK

Reducing the number of bands to what bands are used in the USA, reduces module’s scan time, and
saves power. Bands available in the USA are 2,4,5,12,13.
To enable all US bands
Command Response Description
AT+UBANDMASK=0,6170 OK Setting LTE-M bands
AT+UBANDMASK=1,6170 OK Setting NB-IoT bands
AT+CFUN=15 OK Reset the device to make the
setting effective.

If the device has a MVNO SIM card, then the +UMNOPROF AT command can be set to <mno>=100
and the module can be reconfigured for some of the settings like +URAT, +UBANDMASK and
+USVCDOMAIN appropriately. To be more efficient, for an MVNO SIM that supports multiple network

UBX-18019856 - R13 Registration with LPWAN network Page 28 of 84

C1-Public
 SARA-R41 series - Application note

operators it is recommended that the module use the manual selection (AT+COPS=1) and pick a
preferred target operator and not issue AT+COPS=0.
To get on to AT&T LTE Cat M1 only with +UMNOPROF: 100
Command Response Description
AT+COPS=2 OK Deregister with the network.
It is possible to issue AT+CFUN=0 or AT+CFUN=4
instead of the AT+COPS=2 command.
AT+UMNOPROF=100 OK Set the carrier profile to standard Europe.
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+URAT=7 OK Set the RAT to LTE Cat M1 only.
AT+UBANDMASK=0,2074 OK Set LTE-M band mask to band 2, 4, 5, 12 only.
AT+USVCDOMAIN=2 OK Set the Type of Attach to CS+PS
AT+CPSMS=0 OK Disable PSM [optional]
AT+CEDRXS=0 OK Disable eDRX [optional]
AT+USIMSTAT=4 OK For multi IMSI MVNO SIM cards configure the
+UUSIMSTAT URC to report the (U)SIM toolkit
REFRESH proactive command result.
For more details, see section [Link].
AT+UCUSATA=4 OK For multi IMSI MVNO SIM cards, enable the
+UUSIMSTAT URC by the +UCUSATA AT command.
For more details, see section [Link].
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+UBIP=1 OK Enable BIP indication near boot-up
AT+COPS=1,2,"310410",7 OK Manual registration to AT&T

To get on to Verizon Cat M1 only with +UMNOPROF: 100

Command Response Description
AT+COPS=2 OK Deregister with the network.
It is possible to issue AT+CFUN=0 or AT+CFUN=4
instead of the AT+COPS=2 command.
AT+UMNOPROF=100 OK Set the carrier profile to standard Europe.
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+URAT=7 OK Set the RAT to LTE Cat M1 only.
AT+UBANDMASK=0,4096 OK Set LTE-M band mask to band 13 only.
AT+USVCDOMAIN=2 OK Set the Type of Attach to CS+PS
AT+CPSMS=0 OK Disable PSM [optional]
AT+CEDRXS=0 OK Disable eDRX [optional]
AT+USIMSTAT=4 OK For multi IMSI MVNO SIM cards configure
+UUSIMSTAT URC to report the (U)SIM toolkit
REFRESH proactive command result.
For more details, see section [Link].
AT+UCUSATA=4 OK For multi IMSI MVNO SIM cards, use the +UCUSATA
AT command to enable the +UUSIMSTAT URC.
For more details, see section [Link].
AT+CFUN=15 OK Reset the device to make the setting effective.
AT+UBIP=1 OK Enable BIP indication near boot-up
AT+COPS=1,2,"311480",7 OK Manual registration to Verizon

UBX-18019856 - R13 Registration with LPWAN network Page 29 of 84

C1-Public
 SARA-R41 series - Application note

[Link] Multi-IMSI SIMs

The market continually offers more multi-IMSI SIMs that can roam in different regions and networks.
They are typically offered by MVNO providers. These SIMs can swap IMSI depending on the local
network information and eventually swapping to an IMSI designed to connect to the local network the
SIM supports.
When using such a SIM it is recommend to set:
• +USIMSTAT: 4
• +UCUSATA: 4
The two configurations above will allow the +UUSIMSTAT URC to report the (U)SIM toolkit REFRESH
proactive command result and so to track possible IMSI swap event.
In addition, on each boot it is advisable to enable bearer independent protocol (BIP) status indication
issuing the AT+UBIP=1 command. Having it enabled will notify events for download’s tag or proactive
command’s tag. This is useful to monitor for potential SIM applet updates, which may occur more
frequently for MVNO SIMs than non-MVNO SIMs.

The example shows how to configure the URC to indicate proactive REFRESH events
Command Response Description
AT+USIMSTAT=4 OK For multi IMSI SIM cards (typically MVNO SIM cards),
configure the +UUSIMSTAT URC to report (U)SIM
toolkit REFRESH proactive command result.
AT+UCUSATA=4 OK For multi IMSI SIM cards (typically MVNO SIM cards),
after setting +USIMSTAT, then use the +UCUSATA
AT command to enable +UUSIMSTAT URC.
If enabled, when there is an IMSI swap event, the SIM
applet will issue a REFRESH event and the host can
now be informed via the +UUSIMSTAT URC.
The +CIMI AT command can be used before and/or
after the +UUSIMSTAT URC to track active IMSI
used.
AT+CFUN=15 OK Reboot the module.

The example below shows how to monitor the IMSI with respect to (U)SIM toolkit REFRESH events
and to enable BIP indication per each boot.
Command Response Description
AT+CIMI 732123203818006 Upon boot check IMSI
AT+UBIP=1 OK Enable BIP indication near boot
+UUSIMSTAT: 9 +UUSIMSTAT URC indicates (U)SIM toolkit
+UCUSATA: 4 REFRESH event.
OK
AT+CIMI 234500029813106 Check if IMSI has changed. In this example, it has.
OK

8.2 Registration as PS connection

Use the +CEREG AT command to confirm the module is registered on the LTE network for LTE Cat M1
or NB1. Use the +CREG and +CGREG AT command for CS and GPRS network registration status.
When registering on a LTE Cat M1 or NB1 network the PDN context will be automatically created and
activated; for 2G networks the host needs to manually activate the PDN context using the +CGACT AT
command.

UBX-18019856 - R13 Registration with LPWAN network Page 30 of 84

C1-Public
 SARA-R41 series - Application note

☞ If the uFOTA is enabled and needs to contact the uFOTA server when running on 2G, the LwM2M
will automatically activate the default context.

8.2.1 PS connections at RAT change

When the module changes the RAT any PDP contexts and socket connections will be deactivated and
disconnected. The host will need to re-create and re-activate socket connections. If the module had
open sockets, the +UUSOCL URC will be issued when they are closed at RAT change.
LTE Cat M1 and NB1 networks, implementing the LTE standard, will automatically activate the
default bearer PDP context, <cid>=1. Any other PDP context the host has configured and manually
activated will have to be re-created and re-activated.
The 2G network may require the host to manual activate a PDP context as this is generally a manual
procedure.

8.3 Detecting the access technology

SARA-R4 series modules can connect to different types of access technologies; LTE Cat M1, NB-IoT
and GPRS in the case of SARA-R412M. Because the modules can be configured to automatically
connect to any of these access technologies, there are AT commands the host application can use to
detect what technology is being used.
The best AT command to use is the +COPS command. The +COPS command has a <AcT> parameter
which describes the access technology the module is registered to. However, this command does not
provide a URC when the module is registered.
There are other AT commands that do have a URC when the registration is made. These also describe
the access technology, +CEREG for LTE (Cat M1 or NB-IoT) and +CGREG (GPRS).
Host applications should always enable the URC for +CEREG and in the case of GPRS with
SARA-R412M, +CGREG. When the module registers on the network the application can read the access
technology type from these URCs.
Basic operation would be:
Command Response Description
AT+CEREG=1 OK Set URC for LTE
AT+CGREG=1 OK Set URC for GPRS if using SARA-R412M
<Wait for URC>
AT+COPS? +COPS: 0,0,"Verizon Wireless",7 Read +COPS and check <AcT> parameter for RAT
OK

☞ +CREG is used to describe if the module has been registered in the Circuit Switched Domain too for
Combined Attach modes.

8.4 Mobility
This section describes the procedures of the module when it moves out of range of the currently
serving cell. This could mean entering another cell or moving into an area where there is no cellular
coverage.
If the module loses the synchronization with the serving cell but finds another cell of the same RAT to
camp on, any PDP context and open sockets will be kept. This holds in particular for seamless change
of serving cell with cell reselection or handover procedures.
If the application has configured multiple RATs in the +URAT setting, in case the module cannot select
a cell on the same RAT, it will automatically go through a re-selection process selecting a cell of

UBX-18019856 - R13 Registration with LPWAN network Page 31 of 84

C1-Public
 SARA-R41 series - Application note

another RAT. In this case, PDP contexts will be locally deactivated and socket connections
disconnected accordingly.

8.4.1 Mobility Management procedures

Mobility management procedures differ depending if the module is in idle mode or connected mode:
• Connected Mode Mobility Management describes the procedures when the module has a RRC
connection established with the cellular network.
• Idle Mode Mobility Management holds when the module is synchronized on a cell without an RRC
connection.
Connected Mode Mobility is handled by the eNodeB. The UE is instructed by the eNodeB to provide a
measurement report so that the network can decide if and when the RRC connection has to be handed
over to another cell. This is called Cell-ReDirection or Cell-Handover.
Idle Mode Mobility is handled by the UE using information transmitted in the System Information
Blocks (SIB) broadcast by the cellular NW within the cell. While in idle mode the UE will make
measurements of neighboring cells and based on the cell reselection criteria read in the SIBs it may
choose another serving cell to synchronize with. This procedure is called Cell-ReSelection.

☞ Currently only SARA-R4 series “63” / “73” version modules support Connected Mode Mobility.

8.4.2 Cell to cell (same RAT), connected mode

If the module is currently camped on a cell and exchanging data in connected mode on an RRC
connection, when it moves out of range a Radio Link Failure event will happen and the module will start
to search for other cells.
Uplink messages will be buffered until the new cell is selected and camped on. If the TX buffer is full,
new user attempts to send data will result in an error result code being returned on the AT interface.
The PDP context and any open sockets will be kept while scanning the supported band until the new
cell is found.
When the new cell is found, the buffered messages will be sent.

8.4.3 Cell to no coverage, connected mode

If the module is currently camped on a cell and exchanging data in connected mode on an RRC
connection, when it moves out of range a radio link failure event will happen and the module will start
to scan for other cells.
Uplink messages will be buffered until the module has finished the cell search on supported bands of
the same RAT; if internal sockets were used for data transfer, any UL buffered messages will be lost
since they were not actually delivered, and the socket will be locally closed when the module has failed
to find another cell of the same RAT to camp on. It will then pick the next RAT in the +URAT list, if any,
and perform cell selection.
Once the cell selection is completed and EPS data bearer has been successfully activated, the
application must take care to re-create and re-open the socket to re-establish the data transfer.
If the dial-up network was used, the no coverage transition may result transparent from the
application level since the dial-up may not be released when data cannot be transferred. This depends
on the dial-up functionality implementation on the host PC. In any case, the PDN contexts where the
dial-up network is established will not be released upon entering out-of-coverage condition.

UBX-18019856 - R13 Registration with LPWAN network Page 32 of 84

C1-Public
 SARA-R41 series - Application note

8.4.4 Cell to cell (same RAT), idle mode

If the module is currently camped on a cell and in idle mode, when it moves out of range it will not
detect the synchronization lost immediately due to L1 optimization in paging reception.
When the application sends new data, the module will try to reconnect to the previous cell and fail.
This will cause the module to scan for another cell.
The application data will be buffered while the module scans all supported bands for a new cell.
If there is another cell of the same PLMN available on the same RAT, then the module will find that
cell and camp on it. The buffered application data will then be sent. PDP contexts will be kept.

8.4.5 Cell to no coverage, idle mode

If the module is currently camped on a cell in idle mode, when it moves out of range it will not know it
has moved out of range of the currently camped cell. When the application sends new data, the
module will try to reconnect to the previous cell and fail. This will cause the module to scan for another
cell.
The application data will be buffered while the module scans supported bands for a new cell.
As there is no other cell in range the module will fail to camp, hence it will locally detach from the
network and start a full scan on the next RAT in the URAT list if any. At local detach, any buffered data
will be lost, PDP contexts will be locally deactivated and open sockets will be closed.

8.4.6 Inter-RAT handover and change or RAT

Inter-RAT handover is currently not supported.
However, when the module has no radio coverage on the currently selected RAT, it will re-scan for cells
on the same RAT. If no cell is found, and there are other RATs in the +URAT preferred list, the module
will try scanning on those technologies.
For example, on SARA-R412M the +URAT may be configured for +URAT: 7,9 which means that it
should use LTE Cat M1 if possible but will try 2G network if this fails.

UBX-18019856 - R13 Registration with LPWAN network Page 33 of 84

C1-Public
 SARA-R41 series - Application note

8.5 Registration examples

8.5.1 LTE registration (Cat M1, NB-IoT)
First the application should check to see if the module is configured for the correct connection it
required. In this example it configures for NB-IoT, band 20 in the Standard Europe profile. Also, the
PDP context to contain the APN is set:
Command Response Description
AT+UMNOPROF=100 OK Set the standard Europe profile
AT+CFUN=15 OK Reboot to take effect
AT+URAT=8 OK Set the +URAT AT command to NB-IoT only
AT+CFUN=15 OK Reboot the module to take effect
AT+UBANDMASK=1, 524288 OK Set band to 20 only for NB-IoT
AT+CGDCONT=1,"IP","jtm2m" OK Set APN to “jtm2m”
AT+USIMSTAT=4 OK For multi IMSI MVNO SIM cards configure
+UUSIMSTAT URC to report the (U)SIM toolkit
REFRESH proactive command result.
For more details, see section [Link].
AT+UCUSATA=4 OK For multi IMSI MVNO SIM cards, use the +UCUSATA
AT command to enable the +UUSIMSTAT URC.
For more details, see section [Link].
AT+CFUN=15 OK Reboot the module to make the changes effective.

SARA-R4 series modules will automatically try to connect when they boot. In this case it will be
scanning band 20 only for NB-IoT network. The host application can poll to see when the module has
registered and activated its default PDP context like this:
Command Response Description
AT+CEREG? +CEREG: 0,2 Module is still scanning
OK
AT+CEREG? +CEREG: 0,5 Registered to network (roaming)
OK
AT+CGATT? +CGATT: 0 Module is not attached to network yet
OK
AT+CGATT? +CGATT: 1 Module is attached to network
OK
AT+CGACT? +CGACT: 1,0 Module does not yet have an active PDP context
OK
AT+CGACT? +CGACT: 1,1 Module now has an active PDP context
OK
AT+CGDCONT? +CGDCONT: 1,"IP","j2m2m","91.80 Module has an IP address
.104.82",0,0
OK
AT+USOCR=17 +USOCR: 0 Create a UDP socket. Socket ID 0 is returned
OK
AT+USOST=0,"[Link] +USOST: 0,2 Send 2 bytes to u-blox echo server
",7,2,"AB" OK
<wait for +UUSORF URC> +UUSORF: 0, 2 Socket ID 0 has 2 bytes to read
AT+USORF=0,2 +USORF: 0,"[Link]",7,2," Read back 2 bytes from socket ID 0
AB"
OK
AT+USOCL=0 OK Close socket ID 0

UBX-18019856 - R13 Registration with LPWAN network Page 34 of 84

C1-Public
 SARA-R41 series - Application note

8.5.2 GPRS registration (2G – SARA-R412M only)

First the application should check if the module is configured for the correct connection it required.
This example is configured for 2G RAT with the PDP context to contain the APN:
Command Response Description
AT+UMNOPROF=100 OK Set the profile. In this example MNO profile100 is
selected, since it provides access to 2G RAT1.
AT+CFUN=15 OK Reset the module to complete activate the MNO
profile selection.
AT+UMNOPROF? +UMNOPROF: 100 Check the MNO profile comes up after boot. In this
OK example it is verified correct with 100.
AT+URAT=9 OK Set +URAT to 2G only. Only selected profiles allow
URAT to be reconfigured.1
AT+CFUN=15 OK Reboot the module to take effect.
AT+CGDCONT=1,"IP","jtm2m" OK Set APN to “jtm2m”.
AT+CFUN=15 OK Reboot the module to take effect.

The SARA-R4 series modules will automatically try to connect when they boot. In this case it will be
scanning for a 2G connection. The host application can poll to see when the module has registered
and activated its default PDP context like this:
Command Response Description
AT+CGREG? +CREG: 0,2 Module is still scanning.
OK
AT+CGREG? +CREG: 0,5 Registered to network.
OK
AT+CGATT? +CGATT: 0 Module is not attached to network yet.
OK
AT+CGATT? +CGATT: 1 Module is attached to network.
OK
AT+CGACT? +CGACT: 1,0 2G networks will not automatically activate the PDP
OK context: it must be done this manually (in general).
AT+CGACT=1 OK Module now has an active PDP context.
AT+CGDCONT? +CGDCONT: 1,"IP","j2m2m","91.80 Module has an IP address.
.104.82",0,0
OK
AT+USOCR=17 +USOCR: 0 Create a UDP socket. Socket ID 0 is returned.
OK
AT+USOST=0,"[Link] +USOST: 0,2 Send 2 bytes to u-blox echo server.
",7,2,"AB" OK
<wait for +UUSORF URC> +UUSORF: 0, 2 Socket ID 0 has 2 bytes to read.
AT+USORF=0,2 +USORF: 0,"[Link]",7,2," Read back 2 bytes from socket ID 0.
AB"
AT+USOCL=0 OK Close socket ID 0.

1
For more details, see appendix B5 in SARA-R4 series AT commands manual [2].

UBX-18019856 - R13 Registration with LPWAN network Page 35 of 84

C1-Public
 SARA-R41 series - Application note

8.5.3 SIM Issuer Identification Number detection

☞ This section is only applicable to the SARA-R410M-63B product version.
The SARA-R410M-63B product version features a SIM-lock-like mechanism that only enables the
radio functionality when a valid SIM card is inserted.
Upon boot, the module will read the Issuer Identifier Number (IIN) from the SIM:
• If the IIN is a valid SIM listed in the internal database, it will then automatically set the MNO profile
followed by a module reset to allow the profile to take effect.

Once the MNO profile has been set according to the SIM as described in the above process, then if the
SIM should change from one carrier to another (i.e., SoftBank SIM to DoCoMo SIM), the module will
repeat the above process.

See Table 4 for IIN values stored in lookup database.

☞ For SARA-R410M-63B-00, the firmware IIN internal database was populated on October 2019.
This database includes both MNO and MVNO (Mobile Virtual Network Operator) SIMs.

UBX-18019856 - R13 Registration with LPWAN network Page 36 of 84

C1-Public
 SARA-R41 series - Application note

8.6 Roaming factors

8.6.1 Higher priority PLMN scan when roaming
When the module is registered to a network as a roaming device, and the SIM meets all the following
conditions, then the module will execute a Higher Priority PLMN scan when the scan timer expires
(this timer can be as low as 2 minutes, as it depends on the internal value):
• Enables a Higher Priority PLMN scan associated with a scan timer value.
• There is an OPLMN (Operator Controlled Public Land Mobile Network) list.
• One entry in the OPLMN list has the same MCC (Mobile Country Code) as the current registered
PLMN.
If the host uses data services for more than the timer value, then the data call can be interrupted and
dropped when the scan timer expires and RRC connection is released in order to transition to the scan
process. In such a case, the host must wait for the device to reestablish registration on a valid network
with service. The host will then need to setup a new data service session; the previous data session
will not resume.
If the host wishes to avoid interruption of such a Higher Priority PLMN scan, then manual PLMN
selection with +COPS AT command (<mode>=1, manual mode) can be used.
Other notes and key points:
• AT+COPS=0 command always triggers a high priority PLMN search and performs a full PLMN
scan.
• In +COPS: 2 mode the module radio/ cell state is retained. This means that power consumption will
be higher than in +CFUN: 0 as the module will keep on searching for the most suitable cell.
• The AT+COPS=2 / AT+COPS=0 cycle is to be used when High Priority PLMN search has to be
triggered (for example, in roaming conditions), while AT+CFUN=0/1 cycle shall be used to trigger
a registration cycle.

8.6.2 Data enable/disable roaming feature

SARA-R4 series modules provide the means to disable PDP context when roaming with the
+UDCONF=76 AT command. Some MNO carriers may require this feature to be enabled, which is
disabled by default.

Example on how to enable this feature.

Command Response Description
AT+UDCONF=76,1,1 OK Set data flag high to enable “Disable data when
roaming”.
AT+CFUN=15 OK Reboot the module for the mode to take effect.
AT+UDCONF=76 +UDCONF: 76,1,1 Read to confirm data flag set. The PDP will now not
OK be able to send data when roaming on a network.

UBX-18019856 - R13 Registration with LPWAN network Page 37 of 84

C1-Public
 SARA-R41 series - Application note

8.7 Booting up in offline state

☞ This section is applicable to SARA-R410M-02B-03 and SARA-R412M-02B-03.

When booting-up the module in offline mode such as in airplane mode (+CFUN: 4), then to avoid a
potential conflict with LwM2M leading to an unexpected module reboot, it is recommended to set
disable LwM2M before exiting the airplane mode by setting the module to full functionality to MT
(+CFUN: 1). Following exit, reboot the module to restore LwM2M client.

Command Response Description

Device boots-up in airplane mode.
AT+CFUN? +CFUN: 4 Confirm device is in airplane mode.
OK
AT+ULWM2M=1 OK Shutdown LwM2M client for this session.
AT+CFUN=1 OK Set MT to full functionality from airplane mode.
AT+CFUN=15 OK Reboot the module this way LwM2M will resume
upon boot.

UBX-18019856 - R13 Registration with LPWAN network Page 38 of 84

C1-Public
 SARA-R41 series - Application note

9 Data delivery
SARA-R4 series modules support three different data delivery modes: IP, NON-IP (using either control
plane or user plane) and SMS.
To configure for IP or NON-IP, the host application must configure a PDP context using the +CGDCONT
AT command.
To send NON-IP data the host application must use the +CSODCP AT command. To receive NON-IP
data the host application must configure the data reporting URC with the +CRTDCP AT command. See
section 17 for further information.

9.1 Data planes

SARA-R4 series modules currently support for Cat M1 S1-User Plane data transfer and for NB-IoT
supports S1-Control Plane CIoT EPS Optimization.

9.2 Attach types

Use the +USVCDOMAIN AT command to specify how the SARA-R4 series modules attach to the
network if the default attach type is not supported by the network.
All USA MNO profiles use Combined Attach (CS & PS).
All Europe MNO profiles have Attach Type set to EPS only (PS).

UBX-18019856 - R13 Data delivery Page 39 of 84

C1-Public
 SARA-R41 series - Application note

10 PDP context / Access Point Name (APN)

10.1 Default APNs
When using the +UMNOPROF AT command, a pre-defined APN may be set for the specified network.
For more details, see the section 7.1.
To automatically obtain the default APN from the (non-roaming) network, the module must have a
blank quoted string "" APN configured when using the +CGDCONT AT command. When the module
attaches, the network will provide the default APN for the activated PDP context.
Generally, if using a roaming SIM, the host will have to provide a specific APN, provided by the network
operator the roaming SIM was from.

☞ On the DoCoMo MNO profile of the SARA-R410M-63B product version, the APN must be manually
entered to register with the DoCoMo network.

10.1.1 Verizon attach APN

For the Verizon Wireless network (<mno>=3), the attach APN is configured to a void string in
+CGDCONT. It is expected that the network provides Class 3 Data APN after attach, and this makes
bearer at <cid>=1 available for user data transfer.
In any case the application processor shall treat the attach APN the same as the class 3 APN and
route all internet traffic to this PDN, even if the provisioned APN name in the attach APN differs from
the string available in the Verizon APN table. This behavior complies with Verizon Wireless
requirement VZ_REQ_LTEB13NAC_6352.
Verizon Wireless does not allow the activation of two or more PDNs with the same APN string and IP
type.

☞ On SARA-R410M-02B-03, when the Verizon MNO profile is selected (+UMNOPROF: 3), the module
may not restore the last APN value to blank on CID1 after de-registering with network. It is
recommended that the host monitors the APN value to see if it needs to restore the APN to blank,
or change the APN if another APN is desired upon next registration, e.g., when a SIM, which uses
different APN, is inserted.

10.2 Multiple & private APNs

The host must configure any private APNs using the +CGDCONT AT command. Only the default bearer
(<cid>=1) will be activated when it attaches if multiple contexts/APNs are configured before the
module attaches to the network. The host must activate the other contexts/APNs by using the
+CGACT AT command.

☞ On SARA-R4 "02B" product versions, only one PDP context can be active. Before another PDP
context can be activated the host application must deactivate the current PDP context.

10.3 Authentication
The authentication on APNs can be configured by using the +UAUTHREQ AT command.
AT+UAUTHREQ=<cid>,<authentication_type>,"password","username"

☞ The password comes before the username.

The host can set authentication parameters for each PDP context configured with +CGDCONT. It must
specify CHAP, PAP or none.

UBX-18019856 - R13 PDP context / Access Point Name (APN) Page 40 of 84

C1-Public
 SARA-R41 series - Application note

11 DUN/PPP
When a data call is initiated by means of the D* AT command, the module switches to the PPP mode
just after the CONNECT intermediate result code. The first step of the PPP procedure is the LCP
handshake. SARA-R4 modules will first request the CHAP authentication during LCP negotiation.
• The host can respond with null (empty) username and null (empty) password.
• If the host PPP rejects (Configure-Reject) authentication during any LCP phase, SARA-R4 does
not request any more authentication.
• If the host PPP NACKs (Configure-NAK) CHAP authentication during LCP negotiation, SARA-R4
will then request PAP authentication.
• If the host PPP NACKs (Configure-NAK) PAP authentication during LCP negotiation, SARA-R4 will
request No Auth.
Using dial command for establishing PPP connection: ATD*99***1# the ‘1’ in this example refers to
the first active PDP context returned by the +CGDCONT read command.

☞ For SARA-R410M-02B-00 and SARA-R410M-52B-00, to avoid conflict with the internal uFOTA
client service, the PPP operation should be entered within 30 s of the module boot. If the DUN/PPP
(ATD#99) establishment fails, the application should retry.

☞ For SARA-R410M-02B-04, SARA-R410M-02B-03, SARA-R410M-02B-02, SARA-R410M-02B-01,

SARA-R410M-52B-01, SARA-R410M-52B-02, SARA-R412M, and SARA-R4 “63” / “73” / “83”
product versions the uFOTA client starts earlier from boot and therefore in contrast to previous
firmware it should be attempted 30 s after the module boot.

☞ If the LWM2M LifeTimer should expire during the middle of the module’s run time after boot a
DUN/PPP establishment will fail, and the application should retry.

☞ In regard to device security and data security for SARA-R4 “63” / “73” / “83” product versions, a
PPP/DUN call cannot be established when:
o The device attempts to connect to the u-blox security server to perform a bootstrap
o When a security heartbeat time expires and it attempts to connect to u-blox security service
server
o When the encryption / decryption feature attempts to connect to owner’s platform.

The DUN call should be retired if any of the above cases should be encountered.
For more details on device security and data security, see u-blox IoT Security-as-a-Service
overview [10].

For 2G RAT, on the SARA-R412M the PDP context will be activated by the uFOTA client and released
by the uFOTA client when the data call to the uFOTA server is complete. During this time, the PDP
context cannot be activated by the host via +CGACT nor can it deactivate the context that is
established by the uFOTA client. The host needs to monitor the PDP context upon the boot and start
the DUN call when the PDP context is not activated and available to be used.

☞ After the module has attached to the network the host can control the PDP context APN,
authentication and MTU sizes directly through PPP.

☞ For Windows and non-Windows hosts, the AT&S0 command is needed.

UBX-18019856 - R13 DUN/PPP Page 41 of 84

C1-Public
 SARA-R41 series - Application note

☞ For Windows dial-up the command ATX0 should be configured as the initialization string under
advanced properties of the modem.

☞ If the network throughput is less than the data sent from the host to the module (is limited by
uplink network resource/bandwidth), then a packet data loss may occur, even with hardware flow
control enabled. To avoid this issue do either or both:
o Reduce the baud rate used
o The host application can slow down data transfer by adding pauses between data payloads or
breaking up their payload and adding delay.

☞ When using MUX and PPP combined, toggling the DTR line does not terminate the PPP session
and return the device to the command mode. In this configuration, it is recommended that the
host terminates the PPP session, which can be done by sending LCP_TERM REQ. Another method
to terminate the PPP session is to send a MSC MUX frame for logical DTR de-assert.
If the PSM is enabled and the devices goes into RRC idle state due to inactivity of traffic over the
PPP link, the device will enter the PSM low power mode when the T3324 timer expires.

11.1 PPP over multiple PDP contexts

Optionally, a second PDP context can be set up for PPP if used with multiplexer (multiplexing mode
MUX) over the UART serial port. In such a configuration, the socket type data calls established by AT
commands and internal embedded calls are only routed through the default context CID1.

☞ A different and unique APN is required per context.

In the below example there are two contexts defined and established. The second context on CID2
may be utilized by PPP. Do not active the second context manually, instead establishing the PPP
session will automatically activate and deactivate it. In the example the second context is activated
by the PPP session.

Example of a second context for PPP dial up connection:

+CGDCONT: 1,"IP","APN1","[Link]",0,0,0,0
+CGDCONT: 2,"IPV4V6","APN2","[Link] [Link].[Link].[Link].87.68.176
.1",0,0,0,0

For more details on multiple PDP contexts, see the SARA-R4 series AT commands manual [2].

UBX-18019856 - R13 DUN/PPP Page 42 of 84

C1-Public
 SARA-R41 series - Application note

12 Monitoring module status

12.1 Registration status
The module must be attached to an LTE Cat M1 or an NB-IoT network in order to allow the host to
send or receive any messages.
To check the network registration status, issue the +CEREG read command (+CGREG for 2G
registration). The second parameter of the response provides the registration state.
• 0: the MT is not registered, and it performs a network scan through all enabled RATs
• 1: registered
• 2: not registered, but currently in the process to.
• 3: registration denied. The application should have a re-try mechanism which does not simply try
registration immediately, but has some back-off process
• 4: unknown
• 5: registered, roaming
If the SIM used is an international SIM (roaming SIM) then the registration process can take many
minutes for the first time. Once the module is registered on that network the PLMN should be stored
in the SIM to allow quicker registration next time. The application can tell if it is using roaming SIM by
the state being “5: Registered, roaming”.
The +CEREG URC can be enabled to provide the network registration status. Depending on the <mode>
parameter it is possible to configure the parameters of interest. For more details, see SARA-R4 series
AT commands manual [2].

☞ Setting the +CEREG <mode> parameter to 3, 4 or 5 it is possible to see the registration EMM cause
value. These values are described in the 3GPP TS 24.008 [13]. Typical causes:
o #5 IMEI not accepted
o #11 PLMN not allowed
o #12 Location area not allowed
o #13 Roaming not allowed in this location area
o #22 Congestion

12.2 Viewing IP address

Before sending any IP data to the LPWAN network configure the device with an IP address.

☞ Use the +CGPADDR AT command to read what the IP address of the module has been set to.
The +CGDCONT AT command lists the IP addresses for each defined PDP context.
No IP addresses are displayed until the module has registered on the network and has been provided
with an IP address. The application could simply poll this IP address to see when the entire registration
process has finished.

12.3 Viewing DNS address

For using domain names, and for uFOTA client to operate, the module must have received a DNS IP
address. Use the +CGCONTRDP AT command to view if the module has been assigned a DNS IP address.

⚠ Without a DNS address being assigned to the module by the network, uFOTA client will not
operate.

UBX-18019856 - R13 Monitoring module status Page 43 of 84

C1-Public
 SARA-R41 series - Application note

12.4 AT example
Below is example pseudo code that shows how to manage the registration process in the host
application.
Because the +COPS AT command does not provide a URC when the Radio Access Technology (RAT)
changes on registration, the host application should wait for “any” registration, and then read the RAT
from the +COPS <AcT> parameter:
// (assuming the module is not connected and not scanning i.e., +COPS: 2)

// Enable URCs
AT+CEREG=1
AT+CGREG=1
AT+CREG=1

// Start auto cell scanning/registration (it could be AT+COPS=1,2,”<plmn”> too)

AT+COPS=0

While not registered

<Wait for URC>
If URC = +CEREG: 1 or +CEREG: 5 or +CGREG: 1 or +CGREG: 5 then
AT+COPS?
RAT = <AcT> parameter

// Module will only be registered on either LTE or GPRS,

// so once these URCs return ‘1’ or ‘5’, exit the loop
Registered = true
End if
Loop

// If GPRS, then activate the PDP context (it is not automatic)

If RAT = ‘3’ then AT+CGACT=1

// Wait for PDP vontext to become active

While not PDP_context_active
If AT+CGACT? = ‘1’
PDP_context_active = true
Loop

// Module is now registered and has an active PDP context.

// read the IP address

AT+CGPADDR

UBX-18019856 - R13 Monitoring module status Page 44 of 84

C1-Public
 SARA-R41 series - Application note

13 TCP/UDP sockets
Basic communications to servers can be made using UDP or TCP. The host application will need to
create a socket, and through the socket send and receive data. Multiple sockets can be used at the
same time.

☞ If the module changes RAT any sockets opened at the time will be closed.

☞ Any open sockets will be kept open if the module loses the previous cell and can camp on another
cell without timing out scanning for the new cell.

13.1 Packet switched data configuration – IPv4/IPv6

SARA-R4 module series defines a single profile for the packet switched data for the internal IP stack.
Because there is only one profile, this is handled automatically.

☞ IPv4 is configured by default. If the host application is using IPv6, it must modify the IP type
parameter by means of the +UPSD AT command.
Command Response Description
AT+UPSD=0,0,1 OK Set profile 0, protocol IP type to IPv6

13.2 Domain name addresses

If the network has not assigned a DNS IP address to the module the socket commands will not work
with domain names, only IP addresses.
Check the PDP context dynamic parameters using the +CGCONTRDP AT command. Here it will list the
primary and secondary DNS address.

13.2.1 DNS caching

A resolved DNS Resource Record (RR) is locally cached based on the TTL value sent by the DNS server.
There can be a maximum of 5 entries in the DNS cache. When the maximum entries have been
reached, then new entries will be added, while the oldest entry is removed.
The DNS entry will be added if the TTL value is within the constraint of:
• A maximum TTL allowed is 86400 s
• A minimal TTL allowed is 5 s.
Any TTL value outside the above constraint limits will not be cached.

13.3 Socket buffers

SARA-R4 series modules have transmit and receive buffers for the data sent on the socket. These
buffers allow the host application to send and receive data while the module is performing its own
communication with the cell.
• TCP RX total buffer: 16 kB
• TCP RX window: 16 kB
• TCP TX buffer for each socket: 10 kB
• UDP buffer: 16 kB

UBX-18019856 - R13 TCP/UDP sockets Page 45 of 84

C1-Public
 SARA-R41 series - Application note

13.4 Creating a socket

Create a socket to be able to send UDP data. A socket ID is returned.
Command Response Description
AT+USOCR=17 +USOCR: <socketID>[,<listen_port>] Create a UDP socket.
OK Returns the socket ID to be used with
other socket commands.

☞ For UDP it is possible to specify the listen port with the create socket command. If the listen port
is specified here, there is no need to use the +USOLI AT command. An error result code will be
returned if both procedures are tried.

13.5 Closing a socket

Once a socket is no longer needed, it should be closed.
Command Response Description
AT+USOCL=<socketID>[,<async>] OK Specify the socket ID to close.

It is possible to set the <async> parameter which allows the AT command to complete with the final
result code before the socket has actually closed. If the optional <async> parameter is used the
+UUSOCL URC will be issued when the socket has finally closed.

☞ Issue the +USOCLCFG AT command to enable or disable the closing of the TCP socket on the remote
system when the module is in idle mode. If enabled the module will re-establish the RRC connection
and send a message to the server closing the socket. When this is disabled the module will leave
the server’s socket open when it goes into idle mode.

☞ The +UUSOCL URC will not be issued if the remote host closes the socket until all the received data
has been read using the +USORD AT command.
Per TCP RFC 793 [17], the client can specify a “TIME_WAIT” value, commonly named as linger timer,
for the above socket closing process. Lowering this value could reduce the socket closure time, but by
doing so it would trade off time to ensure the last ACK is sent from the client to the server, where in
context the client is referred to as the initiator of the TCP session and the receiver is the server.
For SARA-R410M-02B-00, SARA-R410M-02B-01, SARA-R410M-52B-00, SARA-R410M-52B-01,
SARA-R412M-02B-00, SARA-R412M-02B-01, and SARA-R4 “63 / 73 / 83” product versions, the linger
timer default value is 30 s.

13.6 UDP
The UDP is a basic way of sending a message to an application server. There are no transport layer
acknowledgements for the message and there is no guarantee the message will arrive at the
destination. To add acknowledgements to these messages consider using CoAP messaging
externally on the MCU. A connection to a server is not needed when using UDP as the SendTo function
contains all the information required.

13.6.1 Sending data

Sending data to an external server is as simple as specifying the socket to use, the remote IP address
and port, and then the length of data, plus the data. The information text response provides the
number of bytes successfully sent.

☞ The maximum length of data that can be sent at a time is 1024 bytes.

UBX-18019856 - R13 TCP/UDP sockets Page 46 of 84

C1-Public
 SARA-R41 series - Application note

Command Response Description

AT+USOST=<socketId>,"<remote_ad +USOST: <socketId>,<length> Send data to the specified IP address and
dress>",<remote_port>,<length>, OK port through the socket noted by the ID.
"<data>"

For direct link with UDP, if the network throughput is less than what the module is attempting to send
(is limited by uplink network resource/bandwidth), then a UDP packet data drop may occur, even with
hardware flow control enabled. To avoid this issue, do either or both:
• Reduce the baud rate used
• The host application can slow down data transfer by adding pauses between data payloads or
breaking up their payload and adding delay

13.6.2 Receiving data

The data reception is performed in two steps. If the module has received data from the network on a
socket that is listening, then a URC is given. From this message, the application can read the data on
the appropriate socket and length.

[Link] Data arrived indicator

Command Response Description
+UUSORF:<socketId>,<length> This message is provided to tell the
application how much data is available to
read on the specified socket.

The application should read this message and then read the data from the specified socket.

[Link] Reading data from socket

The data reception is performed by means of the +USORF command, using the information given in
the +UUSORF URC.
Command Response Description
AT+USORF:<socketId>,<length> +USORF:<socket>,"<ip_addr>",<port> Provides the received data to the
,<length>,"<data>" application.
OK

13.6.3 Testing
A simple way to test UDP sockets over the NB-IoT network is to send data to an echo server.

☞ The u-blox echo server is [Link] at IP address [Link] on port 7.

Here is an example:
Command Response Description
AT+USOCR=17 +USOCR: 1 Create a socket. The socket ID is 1.
OK
AT+USOST=1,"[Link]",7,5, +USOST: 1,5 Send “Hello” to u-blox echo server. Sent 5
"48656c6c6F" OK bytes on socket ID 1.
+UUSORF:1,5 Received 5 bytes on socket ID 1.
AT+USORF=1,5 +USORF: 1,[Link],7,5,"48656 Read 5 bytes on socket ID 1.
c6c6F" Received data information provided…
OK “Hello”.

UBX-18019856 - R13 TCP/UDP sockets Page 47 of 84

C1-Public
 SARA-R41 series - Application note

13.7 TCP
TCP uses transport acknowledgments between the module and the destination server. TCP will
automatically resend any lost packets and therefore is more robust than UDP.
The downside to using TCP is that there are more messages to be sent between the UE and network
and therefore will consume more power.

13.7.1 Connecting to server

After creating the socket the host application needs to ‘connect’ to the server. This connection is kept
open until the socket is closed.
Use the +USOCO AT command to connect to the remote host where the remote address, remote port
is specified.

13.7.2 Writing socket data

Use the +USOWR AT command to write data to a socket, and hence to the remote host connected to.
The module will respond with the number of bytes queued. If the internal buffer is full an error result
code will be returned. Issue the AT+USOCTL=1 command to get the last error.

13.7.3 Receiving data

When data is received from the remote host the +UUSORD URC will be issued. Use the socket and
length parameters of this URC to read the data back from the module to the host application with the
+USORD AT command.

UBX-18019856 - R13 TCP/UDP sockets Page 48 of 84

C1-Public
 SARA-R41 series - Application note

14 MQTT
SARA-R4 series modules can be configured to quickly and easily run the MQTT protocol. This section
provides the minimum configuration required to get the MQTT protocol up and running. There are two
different quick start techniques that can be used to quickly get to an MQTT connection (and
performing MQTT commands):
• Minimal MQTT configuration – it accepts the default values provided for MQTT configuration
• Saved MQTT configuration – it changes the MQTT configuration until it is acceptable and saving
it, thus allowing a quick restore to get back all of the MQTT configuration parameters

14.1 Quick start based on minimal MQTT configuration

u-blox's MQTT implementation supplies a default value for a lot of MQTT's configuration parameters.
However, the MQTT server (i.e., MQTT message broker) has no default value and must be specified in
order to connect. Depending on the configuration of the MQTT server, an MQTT connection might be
possible after specifying only the MQTT remote server information. If the MQTT server requires login
credentials (i.e., username and password), then the username and password must also be configured
in order to create an MQTT connection.

14.1.1 Restore MQTT to factory–programmed setting

The following command restores factory–programmed parameters to MQTT:
AT+UMQTTNV=0

☞ This will overwrite all the MQTT profile parameters currently in the NVM.

☞ Do not execute this command if there is current active MQTT login connection. Otherwise, the
MQTT profile parameters for that connection will be lost.

14.1.2 MQTT client ID specification

When MQTT factory–programmed setting has been restored the client ID should be checked and/or
if needed set manually:
AT+UMQTT=0,"<unique client ID>"

14.1.3 MQTT remote server specification

The MQTT server can be configured using either an IP address or a name.

[Link] Server IP address

The following command specifies the remote MQTT server's IP address:
AT+UMQTT=3,"[Link]"

Where the actual server's IP address substitutes for the "[Link]" placeholder in the example above.

[Link] Server name

The following command specifies the remote MQTT server's name:
AT+UMQTT=2,"[Link]"

Where the actual server's name substitutes for the "[Link]" placeholder used in the
example above. The module will use its internal DNS client for IP address resolution.

UBX-18019856 - R13 MQTT Page 49 of 84

C1-Public
 SARA-R41 series - Application note

14.1.4 MQTT connection

Using the above configuration, an MQTT connection can be attempted.
AT+UMQTTC=1

The command could be used to attempt to make an MQTT connection with the specified MQTT
remote server. If the connection is successful, depending on the product version, the MQTT remote
server will send either:
+UUMQTTC: 1,0 for SARA-R4 “02” / “52” product versions
+UUMQTTC: 1,1 for SARA-R4 “63” / “73” / “83” product versions

This indicates a successful login to an MQTT connection. Any non-zero connection result indicates
the MQTT server refused the MQTT login connection. Once an MQTT connection is established,
MQTT commands are available.

14.1.5 Additional configuration

Either the MQTT server could require additional (non-default) MQTT profile parameters or the user
might prefer different, non-default parameters. Section 14.4 covers different MQTT profile
parameters that might be required for an MQTT login connection.

14.2 Quick start based on saved NV configuration

The second quick start technique involves performing the MQTT configuration parameter setting
before and saving them to NVM (see section 14.2.1). Once a valid set of MQTT client profile
parameters are saved, the user can restore them from NVM by means of AT commands and perform
an MQTT login to create an MQTT connection.

☞ The MQTT remote server must be specified (either by IP address or name) in the saved NVM
configuration for a connection to occur.

14.2.1 Restore from saved NVM - MQTT profile

The following command restores all the previously saved MQTT profile parameters from NVM:
AT+UMQTTNV=1

☞ This will overwrite all the MQTT profile parameters currently in memory, so it should not be
performed if there is currently an active MQTT login connection (since the MQTT profile
parameters for that connection will be lost). The restored MQTT profile parameters were
previously saved using the AT+UMQTTNV=2 command.

14.2.2 MQTT connection

Using the above configuration, an MQTT connection can be attempted. The following command
attempts to make an MQTT connection with the MQTT remote server (specified by the saved NVM
MQTT configuration):
AT+UMQTTC=1

If the connection is successful, depending on the product version, the MQTT remote server will send
one of these URCs:
+UUMQTTC: 1,0 for SARA-R4 “02” / “52” product versions
+UUMQTTC: 1,1 for SARA-R4 “63” / “73” / “83” product versions

This indicates successful login to an MQTT connection. Any non-zero connection result indicates the
MQTT server refusing the MQTT login connection. Once an MQTT connection is established, MQTT
commands are available.

UBX-18019856 - R13 MQTT Page 50 of 84

C1-Public
 SARA-R41 series - Application note

14.3 Connection commands

Once an MQTT login connection is established, the following commands can be sent to the MQTT
server: subscribe, unsubscribe, publish, read messages, and logout. An MQTT client connected to an
MQTT server can decide whether to publish messages to the MQTT server or subscribe to message
reception from the MQTT server or both (publish and subscribe). An MQTT client could even choose
to subscribe to a topic filter that includes the topic names to which the MQTT client publishes
messages.

14.3.1 Subscribe to MQTT topic filter

The following command subscribes a connected MQTT client to a given topic filter:
AT+UMQTTC=4,<max_QoS>,<Topic Filter>

After the MQTT client receives a:

+UUMQTTC: 4,<reason>,<QoS>,<topic_name>

for that <Topic Filter> (indicating the MQTT server successfully subscribed the MQTT client to the
given <Topic Filter>), the MQTT server will send to the MQTT client every published message that
matches the given <Topic Filter>.

[Link] Example
The following command subscribes the MQTT client to all messages published that match the
"/user/ublox" Topic Filter:
AT+UMQTTC=4,0,"/user/ublox"

14.3.2 Publish MQTT message to topic name

The following command sends an MQTT message to the MQTT server with a given Topic Name:
AT+UMQTTC=2,<max_QoS>,<retain>,"<Topic Name>","<Message>"

The MQTT server will send that MQTT message to every MQTT client connected to it that is
subscribed to a topic filter that matches the given topic name.

[Link] Example
The following command publishes the "Hi! ..." message to all the MQTT clients connected to the given
MQTT server whose topic filter subscriptions match the "/user/ublox" topic name:
AT+UMQTTC=2,0,0,"/user/ublox","Hi! This is an MQTT message."

14.3.3 Read MQTT messages received

Upon receiving an MQTT message, the MQTT client will receive an asynchronous notification (URC)
of the reception of an MQTT message with the following format for
SARA-R4 "02" / "52" product versions:
+UMQTTCM: 6,<Num_unread_msgs>

SARA-R4 "63” / “73" product versions:

+UMQTTC: 6,<Num_unread_msgs>"

After receiving the above notification, the host application can send the AT+UMQTTC=6 read command
to list the stored messages. The URC will be issued again, then the topic/message pairs.
SARA-R4 "02" / "52" product versions:
AT+UMQTTC=6
+UMQTTC: 6,1

UBX-18019856 - R13 MQTT Page 51 of 84

C1-Public
 SARA-R41 series - Application note

OK
+UMQTTCM: 6,<Num_unread_msgs>
<topic_name>
<message>
<topic_name>
<message>
…
OK

☞ The format of the message output can be configured with AT+UMQTTC=7,<format> command.

On SARA-R4 "63” / “73" product versions, the read command syntax is:
AT+UMQTTC=6[,<one_message>]

Set the <one_message> parameter to the recommended value of 1 reads one received message at a
time:
AT+UMQTTC=6,1
+UMQTTC: 6,<QoS>,<topic_msg_length>,<topic_length>,<topic_name>,<read_msg_length>,<read
_msg>
OK

14.3.4 Logout
The following command terminates the MQTT connection:
AT+UMQTTC=0

After this command is issued, the MQTT connection to the MQTT remote server no longer exists.
Therefore, no MQTT commands (e.g., publish or subscribe) will work until another MQTT connection
is established.

UBX-18019856 - R13 MQTT Page 52 of 84

C1-Public
 SARA-R41 series - Application note

14.4 Profile parameters

14.4.1 Login credentials
If the MQTT server requires login credentials (i.e., username and password) to make an MQTT
connection, the following command provides the required login credentials:
AT+UMQTT=4,"<Username>","<Password>"

Where the actual <Username> and <Password> replace the <Username>/<Password> placeholders
used in the example.

14.4.2 Client ID
The module attempts to create a default client ID for each module attempting to connect to an MQTT
server, uniquely based on the module's IMEI. It is important that this client ID is unique. Upon receiving
a new login connection, an MQTT server must disconnect any pre-existing connection using the same
client ID. Users may decide to create their own proprietary naming scheme to uniquely identify each
of their MQTT client modules. The following command specifies an MQTT client ID that must be
unique to the MQTT server:
AT+UMQTT=0,"<Unique_Client_ID>"

Where the actual client ID designation replaces the <Unique_Client_ID> placeholder used in the
example. The user may also be required to supply the client ID if the module fails to access its IMEI
and thus fails to create a default client ID.

14.4.3 “Will Message” configuration

The MQTT protocol allows each MQTT connection to assign a will message to be sent when the MQTT
server involuntarily disconnects an MQTT client. Configuring a will message requires four parameters:
will message, will topic, will QoS, and will retain. The following command defines the <Will_QoS>,
<Will_Retain>, and <Will_Topic> parameters:
AT+UMQTTWTOPIC=<Will_QoS>,<Will_Retain>,"<Will_Topic>"

This command defines the <Will_Message> parameter:

AT+UMQTTWMSG="<Will_Message>"

Both of these commands are necessary to define a valid will message for the MQTT client.

14.4.4 List of MQTT profile parameters and AT commands to set them

<Parameter> Meaning Resulting from the following commands
2
CleanSession Whether session state survives across MQTT disconnects AT+UMQTT=12,<CleanSession>
Client ID Uniquely identifies MQTT client to MQTT server AT+UMQTT=0,"<Client_ID>"
2
Client port Local client's TCP port number AT+UMQTT=1,"<Port_Number>"
Inactivity timeout MQTT server times out MQTT client if this timeout is AT+UMQTT=10,<Inactivity Timeout>
exceeded with no activity (also called KeepAlive Duration)
Username Login credentials when connecting to an MQTT server AT+UMQTT=4,"<Username>","<Password>"
Password Login credentials when connecting to an MQTT server AT+UMQTT=4,"<Username>","<Password>"
Server IP address Specifies the IP address of the MQTT remote server AT+UMQTT=3,"<Server IP Addr>"
Server name Specifies the name (to be resolved by DNS into an IP AT+UMQTT=2,"<Server Name>"
Address) of the MQTT remote server

2
Not supported on SARA-R4 "63" / "73" product versions

UBX-18019856 - R13 MQTT Page 53 of 84

C1-Public
 SARA-R41 series - Application note

15 HTTP
HTTP profiles are used to define the remote server. The basic HTTP profile consists of a server name
or IP address and basic authentication (username, password). For HTTPS, the server private
certificate can be specified with USECMNG.

15.1 HTTP with server name only

Example of HTTP with basic server name only:
Command Response Description
AT+UHTTP=0,1,"[Link]" OK Set the server name for the profile 0.
AT+UHTTPC=0,1,"/","[Link]" OK Profile 0, GET request of the default page
to file get_rsp.
+UUHTTPCR: 0,1,1 The +UUHTTPCR URC notifies the
success/failure of the operation (in this
example: success).
AT+URDFILE="[Link]" +URDFILE: "[Link]",737,"HTTP/1.0 Read the file.
……
OK

15.2 HTTP with basic authentication

Example of HTTP with basic login and password credentials for authentication:
Command Response Description
AT+UHTTP=1,0,"[Link]" OK Set the server IP address for the profile 1.
at+UHTTP=1,2,"someusername" OK Set the username.
at+UHTTP=1,3,"somepassword" OK Set the password.
at+UHTTP=1,4,1I j OK Set the authentication type.
AT+UHTTPC=1,1,"/","[Link]" OK Profile 1, GET request of the default page
to file get_rsp.
+UUHTTPCR: 1,1,1 The +UUHTTPCR URC notifies the
success/failure of the operation (in this
example: success).
AT+URDFILE="[Link]" +URDFILE: "rsp_file",967,"HTTP/1. Read the file.
1 200 OK
……
OK

UBX-18019856 - R13 HTTP Page 54 of 84

C1-Public
 SARA-R41 series - Application note

15.3 HTTPS with SSL/TLS security certificate

For HTTPS to access a server with SSL/TLS security certificate, the host needs to configure the
security profile with the certificate that has been imported to the module. See section 16 for more
details about the certificate import process.
In this example, the “[Link] server site is used with a root certificate.

Command Response Description

AT+USECMNG=3 "CA","rootCA","SwissSign Silver List of certificates.
CA - G2","2036/10/25 08:32:46"
OK
AT+USECPRF=2 OK Configure Security Profile ID 2.
AT+USECPRF=2,0,1 OK Set TLS validation to 1.
AT+USECPRF=2,1,3 OK Use TLS v1.2.
AT+USECPRF=2,3,"rootCA" OK Set certificate as rootCA.
AT+UHTTP=0,1,"[Link]" OK Set HTTP profile and server name.
AT+UHTTP=0,6,1,2 OK For HTTP profile 0, enable the security
option with USECPRF ID 2.
AT+UHTTPC=0,1,"/","[Link]" OK Profile 0, GET request of the default page
to file get_rsp.
+UUHTTPCR: 1,1,1 The +UUHTTPCR URC notifies the
success/failure of the operation (in this
example: success).
AT+URDFILE="[Link]" +URDFILE: "rsp",852,"HTTP/1.1 Read the file.
……
OK

UBX-18019856 - R13 HTTP Page 55 of 84

C1-Public
 SARA-R41 series - Application note

16 Secure data
16.1 Certificate format
SARA-R4 series modules do not support the PEM format. Only DER and CER formats are supported.
For a useful reference on how to convert certificates from PEM format, see the support SSL website.

For an example of using OpenSSL application to convert PEM to DER:

openssl x509 -in [Link] -outform der -out [Link]

16.2 DTLS client

The SARA-R4 DTLS client provides an end-to-end secure data transfer over UDP sockets. With DTLS,
UDP datagram should be as good as TCP in terms of packet loss, retransmission, and packet
reordering.

☞ For more details on DTLS, see RFC 6347 [16].

16.2.1 AT commands examples for DTLS client

Command Response Description
AT+USOCR=17 +USOCR: 0 Create a UDP socket.
OK
AT+USECPRF=0,8,"PSK" OK Configure PSK.
AT+USECPRF=0,9,"PSK ID" OK Configure PSK ID.
AT+USECPRF=0,2,0 OK Configure the root certificate.
AT+USOSEC=0,1,0 OK Enable secure socket.
AT+USOCO=0,"[Link]",8447 OK Connect the socket.
AT+USOWR=0,10,"1234567890" +USOWR: 0,10 Sends encrypted data over UDP socket
OK with DTLS session enabled: text format
AT+USOWR=0,10 > Sends encrypted data over UDP socket
+USOWR: 0,10 with DTLS session enabled: binary
OK format.

+UUSORD: 0,10
AT+USORD=0,10 +USORD: 0,10,"1234567890" Read the decrypted data.
OK
AT+USOCL=0 OK Disconnects DTLS and close the socket.

UBX-18019856 - R13 Secure data Page 56 of 84

C1-Public
 SARA-R41 series - Application note

17 Non-IP messaging
Using the Non-IP method of sending and receiving messages saves the overhead of needing to send
a UDP IP header. The UDP header is about 48-60 bytes in length, and so an application sending
100 bytes will send about 160 bytes.
Customers cannot use Non-IP messaging without enablement via the MNO. This is because there is
no destination IP address and therefore the MNO will either store these messages in their own IoT
platform, or will forward these messages on to another service. Either way the customer needs to
understand where these Non-IP messages will go.
To send a Non-IP message use the +CSODCP AT command.

☞ Attach type must be set to EPS only for using the +CSODCP AT command.

UBX-18019856 - R13 Non-IP messaging Page 57 of 84

C1-Public
 SARA-R41 series - Application note

18 Paging, eDRX, PSM and deep sleep mode

The LTE Cat M1 or NB1 protocol allows for power save mode (PSM), and the SARA-R4 series modules
also support a deep-sleep mode where the module is running at low current, ~8 µA. The module
automatically enters various states depending on the device activity. Here below are listed the
common activities and the various states it will be in after registration.
1. The device is in Power Save Mode (PSM) and in deep-sleep; it is already registered and has
nothing to do.
2. A message is queued or the TAU timer has elapsed.
3. The device re-connects to network and sends and receives data. This is in connected state.
4. The RRC connection is released by the network. It is now in idle state.
5. Within T3324 timer, paging happens as per network configuration.
6. Power Saved Mode is entered after T3324 has elapsed.
7. T3412 elapses and Traffic Area Update is triggered, or application sends more data.
The module enters the deep sleep mode when there is no activity, it does not need to be in the PSM.

☞ T3324 and T3412 timers are assigned by the network. The application can request to the network
what timer values it wants, but the network does not need to grant these values.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 58 of 84
C1-Public
 SARA-R41 series - Application note

18.1 eDRX
The 3GPP TS Release 13 introduced a new feature called Extended Discontinuous Reception (eDRX).
This allows the paging to only operate for a period and then again sometime later. In between the
paging windows the module is in deep sleep mode. eDRX operates while the T3324 timer is running
and is specified by several hyper frames (10.24 s).

eDRX cycle – N Hyper-frames of 10.24 s

Paging window (~2.56s cycle)

T3324 period Power Save Mode

The module can still receive downlink messages when it is in the T3324 period. These messages will
be cached by the network knowing the module will be awaken for the next paging window after the
eDRX cycle has completed.

☞ If the eDRX state is changed by enabling or disabling eDRX via +CEDRXS, a AT+CFUN=15 or proper
shut-down/power-up should be applied for eDRX to properly function.

☞ The application can read the network eDRX value using the AT+CEDRXRDP command.

☞ The direct link mode for both sockets and FTP should not be used with HW flow control and eDRX
all three combined together. This combination can lead to the module going into eDRX deep-sleep
during active direct link data transfer session to due potential HW flow control timing leading to
data not being able transfer smoothly and connection timeout.

18.2 Power save mode (PSM)

Power save mode is configured by means of the +CPSMS AT command. Two timers are specified,
T3324 and T3412. These timers are for how long the module will be in active mode, and how long to
wait until the next TAU event. After the T3324 timer expires the module will enter the Power Save
Mode. In PSM the module is in deep-sleep mode and is only consuming approximately 8 µA.

☞ When in PSM the module will not respond to AT commands.

☞ See sections 18.2.2 and 18.2.3 for how to set T3412 and T3324 values in +CPSMS AT command.
Power Save Mode (PSM) allows the device to skip the periodic page monitoring cycles between active
data transmissions. During this implementation, the device becomes unreachable when the PSM is
active, i.e., it will not be able to receive any downlink messages and any downlink messages sent from
the customers cloud application will be lost.
By implementing the PSM, an LTE NB-IoT device can remain in PSM state for as long as 413 days,
determined by the maximum value of the Tracking Area Update (TAU) timer.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 59 of 84
C1-Public
 SARA-R41 series - Application note

During the PSM active state, all the HW components in the device are turned off, and the device will
not monitor page messages or perform any Radio Resource Management (RRM) measurements. The
only component that is running during PSM is the PMIC RTC.
PSM can enable more efficient low-power mode entry/exit, as the device remains registered with the
network and its state maintained during PSM, without having the need to spend additional cycles to
setup registration/attachment after each PSM entry/exit event.
On the SARA-R4 series modules, if the network supports PSM and grants PSM timers to the module
upon attach process or Tracking Area Update (TAU), then the PDP context is retained across PSM
cycles. Any PPP connections, sockets, or other connections must be re-established upon exiting the
PSM. Since the module is essentially in the off state when it goes into the PSM, the behavior is similar
to what would be expected if the module is turned off and turned it back on.
In practice, this makes sense because PSM cycles will typically be greater than 4 hours per GSMA
guidance, so sockets likely will be closed on the server side due to inactivity.
Any settings the host application has made will need to be re-configured again after waking up the
module. For example, ATE0, AT&S0, AT+CMEE, AT+CEREG. Only settings saved in the NVM according to
the SARA-R4 series AT commands manual [2] are kept in PSM.
When the host is using either of the following data services:
• UDP or TCP sockets
• HTTP/HTTPS
• FTP/FTPS
the device can enter the PSM mode during the data service session, if there is an idle period of data
transfer long enough for the network RRC timer to expire, thus releasing the RRC connection from the
network.

☞ For non-data service features such as a download file by means of the +UDWNFILE AT command
the device can enter the PSM during a file transfer.
To avoid interruption of the data service or other features from PSM, disable PSM via the +CPSMS
AT command, execute the desired data service, and when finished, enable PSM with the +CPSMS
AT command.

18.2.1 PSM with customized timer request

Command Response Description
AT+CMEE=2 OK Enabling the verbose error.
AT+CPIN="1234" OK Activating the SIM card.
☞ The SIM card needs to be active to
enter the PSM.
AT+COPS? +COPS: 0,0,"Verizon Wireless",7 Confirming the module has been
OK registered with the current carrier.
AT+CPSMS=1,,,"00011101","00001010 OK Enabling the PSM.
1" Requesting customized timers.
AT+CFUN=15 OK Reboot to enable the PSM.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 60 of 84
C1-Public
 SARA-R41 series - Application note

18.2.2 T3412 timer (Periodic TAU)

Bits 5 to 1 represent the binary coded timer value. Bits 6 to 8 define the timer value unit for the GPRS
timer as follows:
BIT 8 7 6
0 0 0 value is incremented in multiples of 10 minutes
0 0 1 value is incremented in multiples of 1 hour
0 1 0 value is incremented in multiples of 10 hours
0 1 1 value is incremented in multiples of 2 seconds
1 0 0 value is incremented in multiples of 30 seconds
1 0 1 value is incremented in multiples of 1 minute
1 1 0 value is incremented in multiples of 320 hours (Note 1)
1 1 1 value indicates that the timer is deactivated (Note 2)

Example: "01000111" = 7 x10 hours = 70 hours

☞ To allow the PSM to correctly function and allow the module to wake up for a TAU, the minimum
recommended T3412 timer is 90 s, but timer values that are relatively short are not appealing for
power consumption and typically not recommended.

☞ NOTE 1: This timer value unit is only applicable to the T3312 extended value IE and the T3412
extended value IE (see 3GPP TS 24.301 [14]). If it is received in an integrity protected message,
the value shall be interpreted as multiples of 320 hours. Otherwise, the value shall be interpreted
as multiples of 1 hour.

☞ NOTE 2: This timer value unit is not applicable to the T3412 extended value IE. If this timer value
is received, the T3412 extended value IE shall be considered as not included in the message (see
3GPP TS 24.301 [14]).

18.2.3 T3324 timer (Active Time)

Bits 5 to 1 represent the binary coded timer value. Bits 6 to 8 define the timer value unit for the GPRS
timer as follows:
BIT 8 7 6
0 0 0 value is incremented in multiples of 2 seconds
0 0 1 value is incremented in multiples of 1 minute
0 1 0 value is incremented in multiples of deci-hours
1 1 1 value indicates that the timer is deactivated

Example: "00100100" = 4 x1 minute = 4 minutes

18.2.4 PSM modes

On SARA-R4 series modules there are two PSM modes supported, which are:
1. PSM with network coordination: For this mode, if the network grants the use of PSM, the module
will then use PSM with context retention following the granted timers in coordination with
network.
2. PSM without network coordination: In this mode, the module enters PSM by detaching from the
network and does not retain context.
The +UPSMVER AT command allows reconfiguration of the above to either:
• Set AT+UPSMVER=4 to enable PSM with network coordination only.
• Use PSM without network coordination as a fallback solution when PSM is not supported by the
network (+UPSMVER: 15 that is the default setting).

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 61 of 84
C1-Public
 SARA-R41 series - Application note

In the default +UPSMVER: 15 setting, the module has been configured to be power efficient with PSM,
if the module is not granted PSM by the network, it will fall back into PSM without network
coordination. Without network coordination the module will enter PSM by detaching from the network
as soon as there is inactivity and stay in the sleep mode for 54 minutes. When it wakes from PSM
sleep mode, it will need to register with a network once again.
Also, it will periodically enter PSM if it cannot find a network to register on for any +UPSMVER setting.

☞ PDN context / IP address is not retained with PSM without network coordination.
The following is an example of when PSM is not granted by the network and then the module falls back
to PSM without network coordination.
Command Response Description
AT+UPSMVER? +UPSMVER: 15 Read the current +UPSMVER setting (15).
OK
AT+CPSMS=1,,,"00011101","00010101" OK Enabling the PSM and optionally set timers.
In this example: requesting timers are:
• 00011111: 310 minutes (5 hours 10 minutes) for
TAU
• 0001011: 22 s for active timer
AT+CSCON=1 OK Enable radio connection status if not enabled.
AT+UPSMR=1 OK Enable Power Saving Mode indication if not
enabled.
AT+CSGT=1,"Greeting Message" OK Optionally set a greeting message, which is the
text printed when it exists PSM sleep state.
AT+CFUN=15 OK Reboot to enable the PSM.
Greeting Message Greeting message after boot-up.
+CSCON: 1 RRC connection active.
AT+UPSMR? +UPSMR: 1 Check power saving mode indication enabled.
AT+CEREG=4 OK Optionally set the +CEREG mode for registration
status notification and format.
AT+CEREG? +CEREG: 4,1,"2809","29", Let device register
"9EBB01",7,,, The +CEREG read command is one method for an
on-demand check of the registration status and
PSM assigned settings.
AT+UCPSMS? +UCPSMS: 0 The +UCPSMS read command response provides
OK PSM assigned settings. In this case, PSM has not
been granted by the network..
+CSCON: 0 RRC goes idle.
+CSCON: 1 +CSCON indicates RRC is now active to detach
from network in this case, where in this example
sequence it appears right before +UUPSMR: 1
(next URC event below).
+UUPSMR: 1 URC indicating device going into PSM low power
mode.
The device enters PSM without network
coordination.
The key point in this example, is in the above two
URC events +CSCON: 1 appear right before
+UUPSMR:1. This indicates the network did not
grant PSM and therefore the T3324 timer does not
apply.
☞ This is the only way of checking the PSM has
not been granted on SARA-R410M-01B,
SARA-R410M-02B-01, SARA-R410M-02B-02,
SARA-R410M-02B-03, SARA-R410M-52B,

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 62 of 84
C1-Public
 SARA-R41 series - Application note

Command Response Description

SARA-R412M-02B-00, SARA-R412M-02B-01,
SARA-R412M-02B-02, SARA-R412M-02B-03,
SARA-R4 “63B / 73B / 83B” product variants.
Instead +CSCON: 1 is triggered by PSM without
network coordination to detach from the network
to send the module into PSM sleep.
It will remain in PSM for 54 minutes. After it will
wake and will have to attach and register to a
network again.

If the host application does not desire to use the fallback option to PSM without network coordination,
then it can use PSM with network coordination configuration mode only. The guidelines to using it in
this configuration are:
• Set the PSM with network coordination mode only (+UPSMVER: 4).
• If the network does not grant the use of PSM, it is still possible to save power with timed periodic
graceful shutdown and power-up. To implement this fallback alternative, the host should:
o Keep track of requested T3324 and T3412 timers to enter and exit PSM, starting them at
+CSCON: 0.
o Check whether PSM has not been granted by the network via the +UCPSMS and +CEREG read
commands.
o To minimize power consumption at the requested T3324 timer expiry gracefully shut down the
module to detach itself from the network, releasing the present PDP context.

☞ From the shutoff state, power up the module again at the requested T3412 timer expiry. On
SARA-R410M-02B-01, SARA-R410M-02B-02, SARA-R410M-02B-03, SARA-R412M-02B-00,
SARA-R412M-02B-01, SARA-R412M-02B-02, SARA-R412M-02B-03, SARA-R4 “01B” / “52B” /
“63B” / “73B” / “83B” product versions, it is not possible to check whether the PSM has not been
granted by the network via the +UCPSMS and +CEREG read commands. If the +UCPSMS and
+CEREG read commands provide the requested T3324 timer, the only way to know that PSM has
not been granted by network is that the module does not enter PSM when the requested T3324
timer expires.

The following is an example of using PSM on SARA-R4 series:

Command Response Description
AT+UPSMVER=4 OK Set PSM mode to PSM with network coordination
mode only. It is not recommended to use the
default value 15, which has fall back to PSM
without network coordination.
AT+CFUN=15 OK Reboot to enable the PSM with network
coordination mode only.
AT+UPSMVER? +UPSMVER: 4 Confirming set value is 4.
OK
AT+CPSMS=1,,,"00011101","00010101" OK Enabling the PSM and optionally set timers.
In this example: requesting timers are:
• 00011111: 310 minutes (5 hours 10 minutes) for
TAU
• 0001011: 22 s for active timer
AT+CSCON=1 OK Enable radio connection status if not enabled.
AT+UPSMR=1 OK Enable Power Saving Mode indication if not
enabled.
AT+CSGT=1,"Greeting Message" OK Optionally set a greeting message, which the
greeting is printed when it exists PSM sleep state.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 63 of 84
C1-Public
 SARA-R41 series - Application note

Command Response Description

AT+CFUN=15 OK Reboot to enable the PSM.
Greeting Message Greeting message after boot-up.
+CSCON: 1 RRC connection active.
AT+UPSMR? +UPSMR: 1 Check power saving mode indication enabled.
AT+CEREG=4 OK Optionally set +CEREG mode for registration
status notification and format.
AT+CEREG? +CEREG: 4,1,"2809","29", Let device register.
"9EBB01",7,,,, The +CEREG read command is one method to
OK check on-demand registration status and PSM
assigned settings.
AT+UCPSMS? +UCPSMS: 0 The +UCPSMS read command response provides
OK PSM assigned settings. In this case, the PSM has
not been granted by the network.
+CSCON: 0 RRC goes idle.
Now wait for T3324 timer to expire.
If +CSCON: 0 is observed but +UUPSMR: 1 is not
when the requested T3324 timer expires, then it
may be PSM is not supported by the network and
the host should use graceful shutdown as
alternative to minimize power consumption.

18.2.5 PSM indication

There are multiple ways the host application can know when the module is in PSM.
• GPIO “module status indication” – See +UGPIOC AT command
• V_INT monitoring
• RXD monitoring – (if RXD is low for more than 1 character)
• +UPSMR URC – returns ‘1’ when the module is about to enter the PSM.

18.2.6 Host waking module from PSM

When in PSM lower power sleep mode, if the PWR_ON pin is asserted low for a specific time as
specified in SARA-R4 series data sheet [1], the module will exit PSM sleep mode.
Once it exits PSM it can follow one of the two options:
1. If there is no data is transferred over the network or AT command activity, it will go back into PSM
sleep within ~16-18 s
2. If there is MO triggered network activity, it will wait for local radio connection to release and then
for T3324 timer to expire and then go back into PSM sleep mode if no AT command activity.
The following is an example of host waking module from PSM:
Command Response Description
The module is in PSM sleep state. Before T3412
expires, PWR_ON assert event wakes module up
from PSM.
Assert PWR_ON as guided SARA-R4 series data
sheet [1] to wake-up from PSM
Greeting Message The device wakes up from PSM and greeting
message is printed. In this example, greeting
message has been enabled and set.
+UUPSMR: 0 URC indicating device coming out of PSM sleep
mode.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 64 of 84
C1-Public
 SARA-R41 series - Application note

Command Response Description

+UUPSMR: 1 URC indicating device going into PSM sleep mode
in ~16-18 s after PWR_ON toggle and no valid
activity to prevent it from sleeping in PSM.
The device enters PSM.
Again, PWR_ON assert event wakes module up
from PSM.
Greeting Message The device wakes-up from PSM and greeting
message printed
+UUPSMR: 0 URC indicating device coming out of PSM sleep
mode
AT+USOCR=17 +USOCR: 0 Here is an example of sending data.
OK Setup and send some socket UDP data.
AT+USOST=0,"[Link]",7,1 +USOST: 0,5 Send UDP data to destination server.
3,"examplepayload" OK
+CSCON: 1 RRC connection active.
+CSCON: 0 RRC idle.
Now wait for T3324 timer to expire.
+UUPSMR: 1 URC indicating device going into PSM low power
mode.
Device in PSM.
Wait for T3412 timer to expire to exit PSM sleep
mode.

18.2.7 PSM and roaming

When the module is registered on a roaming network (not a home network), and the default
“Automatic network selection” mode is enabled by the +COPS AT command, then the module will
periodically search for a HPMLN (Home Public Land Mobile Network). An active HPLMN search delays
the entry into the PSM until the search is complete. In other words, if the PSM is enabled and T3324
(active timer) expires, the device may not enter the PSM mode if the HPLMN search is running. It must
wait for the search to complete before entering the PSM.
If the device is in roaming condition with “Manual network selection” mode, then there will not be a
HPLMN search to delay PSM entry.

18.2.8 PSM and LwM2M

☞ This section is applicable to SARA-R4 63” / “73”/ ”83” product versions, SARA-R410M-02B-03,
SARA-R410M-02B-04, SARA-R412M-02B-03, and SARA-R412M-02B-04.

With PSM enabled, if AT+ULWM2M=1 is applied to stop the LwM2M client, then when the module
enters the PSM sleep mode and then later exits the sleep state, the LwM2M client will once again
initialize and resume due to its volatile setting. For more details, see SARA-R4 series AT commands
manual [2]. If desired to disable the LwM2M client again, a subsequent AT+ULWM2M=1 command is
then necessary when the client resumes.

UBX-18019856 - R13 Paging, eDRX, PSM and deep sleep mode Page 65 of 84
C1-Public
 SARA-R41 series - Application note

19 Application design for low power

19.1 Static applications
Static applications are characterized by devices that are stationary. Generally, the cell the module
connects to will not change throughout the device’s life, unless the network operator installs new
equipment.
For static applications a single RAT is normally used and Inter-RAT handover is not required.

19.1.1 Battery powered

Battery operated applications should consider all the features provided in 3GPP Release 13, for
example PSM, eDRX, release assistance. However, depending on the applications it may be more
efficient turning the module off completely between sending uplink messages.
Depending on the application type, specific Release 13 power saving features may or may not be
useful. I.e., if the application requires an acknowledgement within a short period of a few seconds,
using eDRX may not be required as the acknowledgement is received before the connected mode is
released (RRC).

19.1.2 Mains powered

Devices which are mains powered need not utilize the power saving features of 3GPP Release 13, but
the application should consider what is best for the network.
The network operator may not allow applications to be continuously connected in connected mode as
this takes up resources on the network.

19.2 Mobile applications

Mobile applications need to have other parameters considered which may not be of interest in static
applications. For example, the TAU update timer may need to be set to a relatively low period so that
the network can track the device’s cell location.

20 GNSS
SARA-R4 series modules support reading NMEA strings from the GNSS receiver through AT
commands. The GNSS device management can be performed through the cellular module as well.

20.1 Power control

GNSS power management is controlled by the +UGPS AT command. This will control the GNSS device
using a configured GPIO. Therefore, the host application must first configure the correct GPIO pin for
GNSS supply control.
Issue the AT+UGPIOC=<gpio_id>,3 command to configure which GPIO pin is controlling the GNSS
supply.

UBX-18019856 - R13 Application design for low power Page 66 of 84

C1-Public
 SARA-R41 series - Application note

21 Testing
21.1 Digital pin testing (+UTEST=10)
Table 2 provides the list of pins that can be tested by means of the AT+UTEST=10 command. The
command allows the user to perform some verifications on all the digital pins of the SARA-R4 series
modules.
Pin number Name Description
6 DSR UART data set ready
7 RI UART ring indicator
8 DCD UART data carrier detect
9 DSR UART data terminal ready
10 RTS UART ready to send
11 CTS UART clear to send
12 TXD UART data input
13 RXD UART data output
16 GPIO1 GPIO
19 GPIO6 GPIO
23 GPIO2 GPIO
24 GPIO3 GPIO
25 GPIO4 GPIO
26 SDA I2C bus data line
27 SCL I2C bus clock line
34 I2S_WA / SPI_MOSI I2S word alignment /
SPI Master Output Slave Input
35 I2S_TXD / SPI_CS I2S transmit data /
SPI Chip Select
36 I2S_CLK / SPI_CLK I2S clock / SPI clock
37 I2S_RXD / SPI_MISO I2S receive data / SPI Master Input Slave Output
42 GPIO5 SIM detection
44 SDIO_D2 SDIO serial data [2]
45 SDIO_CLK SDIO serial clock
46 SDIO_CMD SDIO command
47 SDIO_D0 SDIO serial data [0]
48 SDIO_D3 SDIO serial data [3]
49 SDIO_D1 SDIO serial data [1]

Table 2: SARA-R4 pins for +UTEST=10 testing

Below is an example of configuring GPIO 1 as output and set to high.

Command Response Description
Configure the formatting of the error result
code by means of +CMEE AT command.
AT+COPS=2 OK Deregister the module from the network.
AT+UTEST=1 OK The module enters the test mode.
AT+UTEST=10,1 (pin description returned) Gets the pin information.
OK

UBX-18019856 - R13 Testing Page 67 of 84

C1-Public
 SARA-R41 series - Application note

Command Response Description

AT+UTEST=10,2,"000000000000000000 OK Put the module in interface initialized state;
008000" the command saves the pins status to
restore it at the end of the test. Pins enabled
for testing: GPIO1 pin 16
Where hex: 0000 0000 0000 0000 0000 8000
AT+UTEST=10,3,"000000000000000000 OK GPIO1 is configured for output where the bits
000000" for pin 16 are set low
Where hex: 0000 0000 0000 0000 0000 0000
AT+UTEST=10,4,"000000000000000000 OK GPIO1 is set to high for pin 16
008000" Where hex: 0000 0000 0000 0000 0000 8000
AT+UTEST=10,5 Configurations made by AT+UTEST=10,2;
AT+UTEST=10,3 and AT+UTEST=10,4 are
executed.
AT+UTEST=10,6 000000000000000000008000 Logic digital value measured at modules pins
OK for GPIO1, and "high" level detected.

Below is an example of configuring RTS and CTS as output and set to high. This example can only be
done through the USB interface.
Command Response Description
Configure the formatting of the error result
code by means of +CMEE AT command.
AT+COPS=2 OK Deregister the module from the network.
AT+UTEST=1 OK The module enters the test mode.
AT+UTEST=10,1 (pin description returned) Gets the pin information.
OK
AT+UTEST=10,2,"000000000000000000 OK The command puts the module in Interface
000600" initialized state; the command saves the pins
status to restore it at the end of the test. Pins
enabled for testing: RTS pin 10, CTS pin 11
Where hex: 0000 0000 0000 0000 0000 0600
AT+UTEST=10,3,"000000000000000000 OK RTS and CTS are configured for output where
000000" the bits for the pins 10,11 are set low
Where hex: 0000 0000 0000 0000 0000 0000
AT+UTEST=10,4,"000000000000000000 OK RTS and CTS is set to high for pin 10, 11
000600" Where hex: 0000 0000 0000 0000 0000 8000
AT+UTEST=10,5 Configurations made by AT+UTEST=10,2;
AT+UTEST=10,3 and AT+UTEST=10,4 are
executed.
AT+UTEST=10,6 000000000000000000000600 Logic digital value measured at modules pins
OK for GPIO1, and "high" level detected.

• When a SARA-R4 series module is programmed to enter the end user test mode, the +CFUN: 5
URC will be reported if the module is in +UTEST mode, and it can be used as an indication the
module does not exit properly the +UTEST mode.
• The usage of this command shall be restricted to controlled (shielded chamber/box) environments
and for test purpose only, especially when RF testing.

☞ If the +UGPIOC, +UGPIOR, and +UGPIOW AT commands are used in the same power-up session,
then apply these commands before applying the AT+UTEST=10 command. This will allow
AT+UTEST=10 to interact with the pins effectively, and not have conflicting control with the other
commands.

⚠ u-blox assumes no responsibilities for the inappropriate use of this command.

UBX-18019856 - R13 Testing Page 68 of 84

C1-Public
 SARA-R41 series - Application note

21.2 Testing with network simulators

When testing with network simulators, such as a CMW500 from Rohde & Schwarz as one example
among many, the simulator may not be configured to release the local RRC connection when there is
an idle period.

☞ The +UMACQOSTMR AT command is supported by SARA-R4 “02” product versions except for
SARA-R410M-02B-00, SARA-R410M-02B-01, SARA-R410M-02B-02, SARA-R412M-02B-00, and
SARA-R412M-02B-01.

On products / firmware that feature the +UMACQOSTMR AT command timer, this timer may need to
be disabled to allow certain measurements. RF sensitivity measurements, for example, expect the
local RRC connection to remain in the connected state. If this MAC QoS timer is not disabled, then
after the timer expires, it will release the RRC connection with the simulator and may interrupt the
measurement.

Here is an example of checking for the MAC QoS timer value and setting it
Command Response Description
AT+UMACQOSTMR? +UMACQOSTMR: 35,-1 Check if MAC QoS timer is enabled by reading it. In this
OK example, it is enabled for LTE Cat. M1 with 35 s timer. It is
disabled for NB-IoT.
AT+UMACQOSTMR=0 OK Disabled MAC QoS timer for LTE Cat. M1 with 0 value set.
AT+CFUN=15 OK Reset the device for new value to disable MAC QoS timer.
AT+UMACQOSTMR? +UMACQOSTMR: -1,-1 Confirm MAC QoS timer is disabled, which in this
OK example it is reflected as disabled with “-1” value for both
LTE Cat. M1 and NB-IoT.

Another factor to consider with using a test simulator is the need for using a dedicated test SIM. For
more details, see section 25.1.

UBX-18019856 - R13 Testing Page 69 of 84

C1-Public
 SARA-R41 series - Application note

22 Debugging
22.1 Logging port
SARA-R4 series modules assign the USB interface for logging capabilities.

☞ For full debugging of the module, customers must use a dedicated logging application. Customers
need to request for this debug application, which is licensed. This debug tool is not free to use.

☞ The standard u-blox m-center tool is able to capture a modem log that is limited to certain
message traces. A limitation of the log output is that it lacks over-the-air traces, which are needed
to debug connectivity to the cellular network. A custom m-center version is capable of capturing
the over-the –air traces. m-center includes instructions on how to capture a log through its built-in
help menu. If needed, contact u-blox support for guidance about taking an m-center trace or for
more details on the custom m-center.
• The USB interface for logging will also work in parallel to the AT commands port.
• It is strongly recommended to add USB test points for later debugging.
For application using the UART interface to issue AT commands, the module must boot up without
the USB interface connected to a host device. This allows the UART interface to establish AT
connectivity with the host MCU. After the UART communication is established the USB interface can
be connected for logging.
If the full attachment / registration procedure is desired in the logs or any commands that quickly
follow registration, then the host app shall set the device to minimal functionary with AT+CFUN=0, and
then issue AT+CFUN=1 when ready to log.
Before capturing any logs, ensure the device has the logging bitmask correctly set to enable full
logging output with +ULOG AT command.

Command Response Description

AT+ULOG? +ULOG: 0,("LTE",0x00),("DS",0x00),("LEG",0x00) Check logging bitmask. 0x00 values
OK indicate logging output disabled.
AT+ULOG=2 OK Set logging bitmasks for full logging
output.
AT+ULOG? +ULOG: 0,("LTE",0x1F),("DS",0x1F),("LEG",0x1F) Check logging bitmask. 0x1F values
OK indicate logging output enabled. The
device is ready to take logs, but settings
are not persistent.
AT+ULOG=1 OK Make persistent the present logging
bitmask value (optional step).
AT+CFUN=15 OK Reset the device.
AT+ULOG? +ULOG: 0,("LTE",0x1F),("DS",0x1F),("LEG",0x1F) Check the logging bitmask after module
OK reset. 0x1F values indicate logging
output enabled as expected because
AT+ULOG=2, then followed by
AT+ULOG=1 option applied successfully.
The device is ready for logging.

UBX-18019856 - R13 Debugging Page 70 of 84

C1-Public
 SARA-R41 series - Application note

23 Migration
23.1 SARA-G3
23.1.1 PDP activation
The PDP context activation is the same on SARA-R412M in 2G network (+URAT: 9).

23.1.2 +UPSDA
SARA-R4 series modules will automatically activate sockets on <cid> =1 (PDP context id).

24 SMS
24.1 SMS preferred message storage
The factory-programmed value for SARA-R4 series is "ME" for the three memory parameters
<mem1>, <mem2>, and <mem3>. The setting can be set or read by +CPMS. However, on SARA-R4
modules, the memory storage must be all the same type and cannot be mixed.
This is an example of setting the +CPMS storage parameter for all memory parameters to the same
value.
Command Response Description
AT+CPMS="ME","ME","ME" +CPMS: 0,23,0,23,0,23 Set all three memory storage parameters
OK to “ME” memory storage.
AT+CPMS? +CPMS: "ME",0,23,"ME",0,23,"ME",0,23 Read the storage setting back.
OK

For more details on the +CPMS AT command, see SARA-R4 series AT commands manual [2].

25 SIM
25.1 Chip SIM
For devices utilizing a physically soldered down chip SIM, consider what network or networks the
device will connect to. More specifically, beyond the obvious intended end network(s) the device will
deploy on, keep in mind the need to connect with a test network or base station simulator call-boxes,
which may require a specific UICC profile to connect to. Anticipate such needs and be prepared to be
able to obtain and configure a profile to connect to such networks or simulators. Alternatively,
configure a device(s) with a SIM card holder for physical removable SIM for such engineering or pre-
production activities.

UBX-18019856 - R13 Migration Page 71 of 84

C1-Public
 SARA-R41 series - Application note

26 WWAN adapter
☞ The Qualcomm WWAN adapter is not supported by u-blox.

26.1 Disabling Qualcomm WWAN adapter

When connecting the SARA-R4 module to a Windows based PC, ensure the WWAN adapter is
disabled. By default, it will be enabled and therefore it requires a “right click” in Windows over this
adapter to bring up the menu to disable it.
For Microsoft Windows 10, the operating system is set to connect to the WWAN adapter
automatically. If connected, it routes data traffic from the PC to the cellular network via SARA-R4.
Disable this adapter to log and perform device data calls.

Figure 3: Windows Device Manager: Qualcomm WWAN port that needs to be disabled

UBX-18019856 - R13 WWAN adapter Page 72 of 84

C1-Public
 SARA-R41 series - Application note

27 EFS Backup & Restore

☞ EFS / Backup & Restore feature is not supported on SARA-R4 “52” / “63” / “73” / “83” product
versions, SARA-R410M-02B-00, SARA-R410M-02B-01, SARA-R410M-02B-02,
SARA-R412M-02B-00, SARA-R412M-02B-01, and SARA-R412M-02B-02.
Due to the nature of Flash memory, the Embedded File System (EFS) may incur memory corruption if
the safe & graceful shutdown procedure outline in the SARA-R4 series system integration manual [3]
is not followed. It is possible that memory corruption may result in the device being inoperable or
impact specific device data info.
For fatal memory corruption, the EFS Backup & Restore allows the module to autonomously restore
the EFS using the last EFS backup stored on the module itself.
Backup of device’s unique parameters (like for example RF calibration data, IMEI, etc) is performed at
the u-blox factory and is stored on the module as the first backup copy for the device. The host
application has the option to make subsequent backup to supersede the previous backup copy. If EFS
corruption is detected, then the restore is triggered autonomously at the device boot-up process to
restore the device with the single backup copy stored on the device.
Backup & Restore is a unique feature that may extend the lifetime of the modules in the field.

☞ It is critical that the host application follows the proper safe & graceful shutdown procedure
outline in the SARA-R4 series system integration manual [3]. Backup & Restore feature is
intended only as an addition backup mechanism, if on the potential rare occasion, the host
application shutdown is not conforming to the graceful power down guidelines.

27.1 Description
There are two parts to the EFS (Electronic File System) backup & restore feature for SARA R410M
and SARA-R412M module product types with FW versions that support this feature.
The backup feature is optional for a device that comes with this feature from the factory, where the
host can perform a backup of the file system to supersede the previous or original backup done during
the module production. This will allow the latest user values in the file system to be captured in the
backup copy. This includes NV settings, current MNO profile, user files and certificates.
There is a special case where the backup counter goes to zero from a non-zero value. For more details,
see section 27.1.1.
The restore feature allows the modules to automatically recover from a fatal file system corruption,
where the module cannot fully boot up. The module uses this function when it detects such a
corruption from a previous improper shutdown at the next module boot-up. For deployed field devices,
if the corruption is non-fatal and the module can boot up, the host can manually trigger a restore.
There are three known types of non-fatal corruption:
• Loss of IMEI
• MNO profiles lost or duplicated
• Device goes into the non-signaling mode (for more details, see the +UTEST=10 AT command in
the SARA-R4 series AT commands manual [2])

☞ Only in one of the above conditions should a restore be host triggered.

UBX-18019856 - R13 EFS Backup & Restore Page 73 of 84

C1-Public
 SARA-R41 series - Application note

27.1.1 EFS backup

The EFS backup can be initiated with the +UBKUPDATA AT command and will automatically trigger
a module reset upon receiving the command. After the backup process has finished, the device will
perform another reset and store status information that can be queried with an AT command. After
the device is finished with the backup, no further action is required.
The host can issue backup on an infrequent & rare basis that justifies for such a need to perform a
backup. This could be when some important and significant information in the file system has
changed or been added via AT commands. One likely point of needing a backup is after the host
application factory initial "production", which may include configuration of the module to a specific
use case requirement. The backup command can also be used to query how long it has been since the
last backup.

☞ It is recommended to enable greeting text messages via the +CGST AT command after first
power-up at the host application factory. It is also recommended to trigger a manual backup after
the device has been fully configured at production. This way if the restore event should occur in
the field, the greeting text will help to indicate that the AT interface is available and the module is
ready to run with the production configuration.
Additionally, there is a special case when host can issue a backup: backup counter for number of
backups goes to zero from a non-zero value. This counter can be read and monitored with the
+UBKUPDATA AT command.

☞ Modules with factory-programmed configuration come with a backup copy and therefore the
backup counter would be 1, which should be verified in host device production. If this counter
should later go to 0, the host should trigger a backup and then after completed, verify the counter
has a value of 1.
The command's query response contains the number of backups and restores for each file system.

☞ There are not multiple backup “versions” stored; only a single copy of the latest backup is kept.

☞ To avoid excessive flash wear, the backup should be performed on a limited basis such as after
host application production and initialization.

☞ It can take up to 15 s for a backup to execute. This time includes the boot-up time.
To detect when the backup function is complete, and the AT interface is available here are following
options:
• Wait for +UUBKUPDATA URC
o Example for backup successful: +UUBKUPDATA: 1,1
• Loop AT until the OK final result code is issued
o Example: send AT every one second until the OK final result code is got
• Enable and monitor GPIO for “Module status indication” via +UGPIOC AT command
• Enable and monitor greeting message +CSGT

27.1.2 EFS restore

When an automatic restore is triggered, the device will immediately reset (this may interrupt any
currently running processes) and reset/restore the file system. The device will then reset again, and
store status information that can be queried with an AT command. After the device is finished with
the restore, no further action is required, although some settings may need to be restored manually
by the user, if they were modified since the last backup.

UBX-18019856 - R13 EFS Backup & Restore Page 74 of 84

C1-Public
 SARA-R41 series - Application note

If the restore process is interrupted (e.g., through power pull), the process will start from the
beginning again at next boot-up.
There is no available indication to the host processor that a restore is taking place during boot up; it
would just appear as if boot-up is taking longer than typical. If a restore should take place, then the
host processor would need to allow more time for the device to handle the restore, until the AT
interface is made available.

☞ It can take up to 15 s for a restore to execute. This time includes the boot-up time.
The host can detect when a restore has taken place by URC notification.
Example: the +UUBKUPDATA: 2,1 URC indicates restore has taken place and is successful.
A manual restore can be triggered when one of the following conditions is detected by the host in the
field:
• Loss of IMEI, which can be checked and detected with the +CGSN or ATI command, where:
o The +CSGN AT command would return the "+CME ERROR: memory failure" error result code
o The ATI command for Identification Information would return a blank IMEI in the response
• MNO profiles lost or duplicated, which can be checked and detected by the +UMNOPROF AT
command
• The device goes into the non-signaling mode and is unable to exit with AT+UTEST=0 and the
+CFUN AT command cannot change its state from a value of 5. This non-signaling state can be
checked and detected with the +CFUN read command, where the device would return a value of 5.

Restore is only intended for the above situations, and the host should verify that the restore operation
corrects the issue if executed.

Example on using the +CGSN and ATI command to detect lost IMEI
Command Response Description
AT+CGSN +CME ERROR: memory failure Error response indicates lost IMEI using
+CGSN command. The error response
format differs between each +CMEE
setting. The example shown here is for
+CMEE: 2.
ATI Manufacturer: u-blox Blank IMEI indicates lost IMEI using ATI
Model: SARA-R410M-02B command
Revision: L0.[Link].12 [Jan 01
2021 12:00:00]
IMEI:

OK

With the possibility of a restore event, to detect when the module boot-up is complete and AT
interface is available here are following options:
• Loop AT until the OK final result code is issued
o Example: send AT every one second until the OK final result code is received
• Enable and monitor GPIO for “Module status indication” functionality via the +UGPIOC AT
command
• Enable and monitor the greeting message via the +CGST AT command
• Both the module status indication and greeting message option would require to be enabled and
then saved into the EFS backup copy. If a restore should ever be triggered, then the EFS backup
copy would be restored with the feature enabled.

UBX-18019856 - R13 EFS Backup & Restore Page 75 of 84

C1-Public
 SARA-R41 series - Application note

27.1.3 Creating backup after flashing FW update with delta package

If a FW build with the Backup & Restore feature is being updated via FOTA / uFOTA with a delta
package, then after the successful update the host needs to perform a backup with +UBKUPDATA
AT command before testing or relying on this the Restore feature.

27.1.4 Automatic EFS backup performed after EasyFlash

After a successful firmware flash using EashFlash as indicated by the green graphic user interface
progress bar and “SUCCESS!” status message, the module is armed to trigger a backup upon the first
boot. Do allow the boot-up and backup time for the backup process, as guided by in section 27.1.1. If
the device is left powered on after the EasyFlash process is complete it will automatically boot and
perform the backup.

Figure 4 Flashing module is completed. Module will boot-up after success and perform first Backup.

UBX-18019856 - R13 EFS Backup & Restore Page 76 of 84

C1-Public
 SARA-R41 series - Application note

After the first backup is performed automatically post flashing with EasyFlash, confirm the backup
copy.
Command Response Description
AT+UBKUPDATA? +UBKUPDATA: 0,0,1,0,0,0,"" Backup copy confirmed as indicated by
OK the “1” for one backup performed.

27.1.5 EasyFlash and SMS storage

If a FW build with the Backup & Restore feature is being flashed onto a module via EasyFlash, after a
successful flash when the device boots up, then the host is required to set preferred SMS message
storage with +CPMS AT command just once after flashing. This step is required if the host application
should use SMS. If it does not intend to use SMS, then this step can be ignored. Even if the host
intends to use the +CPMS factory-programmed setting, the storage setting still needs to be set.

UBX-18019856 - R13 EFS Backup & Restore Page 77 of 84

C1-Public
 SARA-R41 series - Application note

Appendix
A LTE Cat M1 vs NB1
SARA-R4 series modules can communicate using the 3GPP LTE Cat M1 and NB1 technologies. They
both have features based on the 3GPP Release 13 specification.
Rel. 13 Cat M1 Rel. 13 NB-IoT
Deployment In-band LTE In-band, guard band LTE, and standalone
Coverage 155.7 dB 164 dB
Downlink OFDMA, 15 kHz tone spacing, Turbo code, 16 QAM, OFDMA, 15 kHz tone spacing, TBCC, 1 Rx
1 Rx
Uplink SC-FDMA 15 kHz tone spacing, Turbo code, 16QAM Single tone, 15 kHz and 3.75 kHz spacing
SC-FDMA, 15 kHz tone spacing
Turbo code
Bandwidth 1.08 MHz (6 resource blocks) 180 kHz (1 resource block)
Duplexing FD, HD (Type-B), FDD/TDD HD only (Type-B), FDD-only (TDD for future releases)
Peak rate (UL/DL) 1 Mb/s DL and UL DL – ~32 kb/s (in-band), 34 kb/s (standalone)
UL – ~66 kb/s multitone, ~17 kb/s single tone
Power saving PSM, eDRX, DRX PSM, eDRX, DRX
Power class Class 3 (23 dBm) Class 3 (23 dBm)
Core network Same as LTE Simplified core network(optional), small data
enhancements (data over NAS or user plane with
security context in RAN) (additional non-IP data
support)

UBX-18019856 - R13 Appendix Page 78 of 84

C1-Public
 SARA-R41 series - Application note

B Glossary
Abbreviation Definition
3GPP 3rd Generation Partnership Project
APN Access Point Name
AT AT Command Interpreter Software Subsystem, or attention
BIP Bearer Independent Protocol
CHAP Challenge Handshake Authentication Protocol
DCE Data Communication Equipment
DL Downlink
DLCI Data Link Connection Identifier
DRX Discontinuous Reception
DTE Data Terminal Equipment
DUN Dial-up Networking
eDRX extended Discontinuous Reception
EMM EPS Mobility Management
EPS Evolved Packet System
FDD Frequency Division Duplex
FOTA Firmware Over The Air
FTP File Transfer Protocol
GNSS Global Navigation Satellite System
GPIO General Purpose Input Output
GPRS General Packet Radio Service
GPS Global Positioning System
GSMA GSM Association
HTTP HyperText Transfer Protocol
ICCID Integrated Circuit Card ID
IIN Issuer Identifier Number
IMEI International Mobile Equipment Identity
IP Internet Protocol
L1 Layer 1
LCP Link Control Protocol
LPWAN Low-Power Wide-Area Network
LTE Long Term Evolution
M2M Machine to Machine
MCU Multipoint Communication Unit
MDN Message Disposition Notification
ME Mobile Equipment
MNO Mobile Network Operator
MQTT Message Queueing Telemetry Transport
MSC Modem Status Command
MT Mobile Terminated
MVNO Mobile Virtual Network Operator
NAS None Access Stratum
NB-IoT Narrow Band IoT
NMEA National Marine Electronics Association

UBX-18019856 - R13 Appendix Page 79 of 84

C1-Public
 SARA-R41 series - Application note

Abbreviation Definition
NVM Non Volatile Memory
NW Network
OFDMA Orthogonal Frequency-Division Multiple Access
PAP Personal Authentication Protocol
PDP Parallel Data Protocol
PLMN Public Land Mobile Network
PPP Point-to-Point Protocol
PS Protocol Stack
PSM Power Save Mode
RAN Radio Access Network
RAT Radio Access Technology
RF Radio Frequency
RRC Radio Resource Control
RRM Radio Resource Management
RTC Real Time Clock
RX Reception
SC-FDMA Single-carrier FDMA
SIM Subscriber Identification Module
TAU Tracking Area Update
TCP Transmission Control Protocol
TDD Time Division Duplex
TX Transmission
UART Universal Asynchronous Receiver-Transmitter
UDP User Datagram Protocol
uFOTA u-blox FOTA
UL Uplink
URC Unsolicited Result Code
USB Universal Serial Bus
Table 3: Explanation of the abbreviations and terms used

UBX-18019856 - R13 Appendix Page 80 of 84

C1-Public
 SARA-R41 series - Application note

C SIM issuer identification number database

Table 4, Table 5, and Table 6 provide the list of SIM issuer identification number (IIN) database. These
databases are used when either auto select MNO profile 1 is used or with the IIN detection feature
found on SARA-R410M-63B-00.
The IIN database presented in the tables are for what comes from the factory loaded by the carrier
profiles loaded for a given firmware.
If the profile is not listed, then there are no IIN values related to that profile as in example MNO profile
100 (Standard Europe).

NTTDoCoMo SKT SoftBank Telstra

SARA-R410M-63B-00 898110 898103 898205 898211 898100 898120
SARA-R410M-73B-00 898165 898170
898171
SARA-R410M-83B-00 896101
Table 4: SARA-R410 “63” / “73” / “83” SIM INN values stored on device database used for MNO profile selection

AT&T China Telecom Deutsche Telekom Sprint

SARA-R410M-02-00 8901410 8901030 898603 898606
8901150 8901170 898611 8985302
8901560 8901680 8985307
890138
SARA-R410M-52-00 8901410 8901030
8901150 8901170
8901560 8901680
890138
SARA-R412M-02-00 8988228
SARA-R410M-02-01 8901410 8901030 898603 898606 8988228 896101
SARA-R410M-02-02 8901150 8901170 898611 8985302
8901560 8901680 8985307
890138
SARA-R410M-52-01 8901410 8901030
SARA-R410M-52-02 8901150 8901170
8901560 8901680
890138
SARA-R412M-02-01 8901410 8901030 8988228
SARA-R412M-02-02 8901150 8901170
8901560 8901680
890138 8901253
8901288 8901284
Table 5: SARA-R410M and SARA-R412M “02” / “52” product versions SIM IIN values stored on device database used for
MNO profile selection (part I)

Telstra T-Mobile US Vodafone Verizon

SARA-R410M-02-00 894410 8988239 891480 891004
894410 891005 891012
891650 891433
891444 891483
891486 891487
891489 891808
SARA-R410M-52-00 891480 891004
891005 891012

UBX-18019856 - R13 Appendix Page 81 of 84

C1-Public
 SARA-R41 series - Application note

Telstra T-Mobile US Vodafone Verizon

SARA-R410M-52-01 891480 891004
SARA-R410M-52-02 891005 891012
SARA-R412M-02-00 891223 890124 8949024 8944302 894410 8988239
8901026 8901160 894410
8901260 8901490
SARA-R410M-02-01 891480 891004
SARA-R410M-02-02 891005 891012
SARA-R410M-02-03 891650 891433
891444 891483
891486 891487
891489 891808
SARA-R412M-02-01 8949024 8944302 894410 8988239
SARA-R412M-02-02 8901026 8901160 8935502 8942031
SARA-R410M-02-03 8901260 8901490 894920 893005
8901210 8901230 8935402 893910
8901240 8901270 8935601 893144
8901310 8901580 8935101 894001
893456
Table 6: SARA-R410M and SARA-R412M “02 / 52” product versions SIM IIN values stored on device database used for MNO
profile selection (part II)

UBX-18019856 - R13 Appendix Page 82 of 84

C1-Public
 SARA-R41 series - Application note

Related documentation
[1] u-blox SARA-R4 series data sheet, UBX-16024152
[2] u-blox SARA-R4 series AT commands manual, UBX-17003787
[3] u-blox SARA-R4 series system integration manual, UBX-16029218
[4] u-blox SARA-R4 series Firmware update application note, UBX-17049154
[5] u-blox SARA-R5 / SARA-R4 series GNSS implementation application note, UBX-20012413
[6] u-blox Mux implementation in cellular modules application note, UBX-13001887
[7] u-blox LwM2M objects and commands, UBX-18068860
[8] u-blox EVK-R4 user guide, UBX-16029216
[9] u-blox LTE attachment & transport planes presentation, UBX-19006672
[10] u-blox IoT Security-as-a-Service overview,
[Link]
[11] 3GPP TS 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification
[12] 3GPP TS 36.101 – LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment
(UE) radio transmission and reception
[13] 3GPP TS 24.008 - Annex G (informative): 3GPP specific cause values for mobility management
[14] 3GPP TS 24.301 - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
Stage 3
[15] 3GPP TS 27.010 - Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol
[16] RFC 6347 - Datagram transport layer security (DTLS)
[17] RFC 793 - Transmission control protocol (TCP) protocol specification

☞ For regular updates to u-blox documentation and to receive product change notifications, register
on our homepage ([Link]).

Revision history
Revision Date Name Status / Comments
R01 25-Oct-2018 pwar / clee Initial release
R02 07-Dec-2018 pwar / clee Review release
R03 04-Feb-2019 pwar / clee General release
R04 08-Feb-2019 pafe Extended document applicability to SARA-N4 series
R05 19-Jun-2019 pwar Minor updates
R06 30-Sep-2019 skri / clee Added SMS
R07 27-Jan-2020 clee Extended document applicability to SARA-R410M "63" / "73" product versions
R08 12-Jun-2020 clee Extended document applicability to SARA-R410M-83B product version
Added disabling WWAN adapter
R09 03-Sep-2020 clee Minor updates
R10 10-Dec-2020 clee Minor updates
R11 03-Mar-2021 clee Added EFS backup & restore
R12 17-Sep-2021 clee Minor updates
R13 08-Jul-2022 clee Added guidance of 1. configuration for T-Mobile US network, 2. multi IMSI MVNO
SIMs, 3. performing a restore if Backup/Restore counters go to zero.
Updated section: PSM Modes

UBX-18019856 - R13 Related documentation Page 83 of 84

C1-Public
 SARA-R41 series - Application note

Contact
For further support and contact information, visit us at [Link]/support.

UBX-18019856 - R13 Contact Page 84 of 84

C1-Public