General operation

Start up and initialization

The characteristics of the boot of the cellular device vary from module to module and are described in the corresponding system integration manual. During the boot phase the module might not respond to the AT interface until all necessary SW modules have been installed (e.g. USB drivers). Monitoring of the greeting text, where supported, can help in detecting the successful end of the boot phase.

A complete start up including cellular network operation can only take place with a SIM card.

If the SIM card has enabled the PIN check, some commands answer with "+CME ERROR: SIM PIN required" and most cellular functionalities are not started. After entering the required PIN via the +CPIN command, or if booting with a SIM with disabled PIN check, SIM initialization is carried out and a lot of SIM files are read: it is possible that some commands (e.g. phonebook AT commands) are affected by this preliminary phase, resulting in a temporary error response.

Auto-registration

If the +COPS <mode> parameter in the profiles or in NVM is left to its factory-programmed value 0 or is set to 1, then after SIM initialization, all u-blox modules will automatically perform PLMN selection and registration for circuit switched/non EPS services as well as packet switched/EPS services. Auto-registration (also sometimes called "auto-COPS", not to be confused with automatic <mode>=0) will also be triggered at SIM insertion, for modules supporting SIM hot insertion, or at SIM driver recovery, occurring when the communication with the SIM card is re-established by the module after an unrecoverable error, caused e.g. by mechanical vibrations or electrical interference.

During the auto-registration any further network request (by means of AT+COPS=0 or AT+COPS=1) is processed immediately.

The user can retrieve the result of the auto-registration by polling the registration status commands (e.g. +CREG/+CGREG/+CEREG/+CIREG) or enabling their unsolicited notifications. If auto-COPS is running, at boot time or at SIM insertion, network service commands issued by the user might have a longer response time than expected; this is particularly visible when the module is switched on in a jammed condition, or with a roaming SIM card that shall perform several registration attempts before gaining access to a VPLMN. If the automatic registration fails and the cause cannot be retrieved via +CEER, it is suggested to disable auto-COPS starting the module in +COPS: 2 or in airplane mode +CFUN: 4 and trigger registration with AT commands.

Maximum vs typical response time of cellular network related AT commands

The AT command manual provides the response time as the maximum delay to get the final result code; the execution of an AT command which requires interaction with the network (e.g. PDP context activation) or with a remote server (e.g. connection of a TCP socket) is affected by several aspects, like the reliability of the radio link, which might introduce packet loss and imply re-transmissions, and the quality of the network coverage, which can force the module to look for a better serving cell or even for a different PLMN or Radio Access Technology. Provided that radio conditions are good (diagnostic commands like +CESQ, +CGED , +UCGED can report that) and the module is already registered, the typical response time is really low (e.g. a few seconds); and if the module is already in RRC connected state (so it does not need to establish the RRC connection) it is even lower. The response time will therefore range between the typical response time in good conditions and the documented maximum response time. The host application usually sets a timer for each AT command issued on the AT interface, at whose timeout it take countermeasures like:

  • aborting the current command (if supported),

  • triggering a registration cycle to restart the cellular protocol stack from a known state,

  • triggering a SW reset.

Such host application timer can be configured as the documented maximum response time of the specific AT command issued, or to a shorter value provided that the module is in a known initial state (e.g. registered). In the latter case the timer duration can be theoretically derived from some frequent abnormal cases like the following:

  • loss of one of the module’s messages or network response,

  • collision between the service request and some mobility procedure

and set to some tens of seconds. When there is no information on the module registration status, like at switch on, it is advisable to wait more, because the mobility procedure might last much longer due to e.g.:

  • initial PLMN scan on all supported bands and RATs to find the highest priority PLMN in roaming condition; if NB-IoT is among the supported RATs, 2 minutes might be required to scan each NB-IoT band;

  • registration attempts on several PLMNs rejecting the module due to subscription limitation; in legacy RATs (2G, 3G) this occurs within the steering of roaming (SoR) feature and can extend the registration response time to more than the 3 minutes calculated as worst case in a single PLMN (at least 4 minutes are suggested in this case).

If the current command is aborted and re-issued, it might be that the module can never complete the required steps to find a suitable cell and PLMN and register on it. This holds in particular for the registration commands AT+COPS=0 issued in +COPS: 2. So it is suggested to use a larger timeout value at least once, before taking countermeasures like triggering a registration cycle or a SW reset.

AT commands types

Action command

An action command forces the DCE to print information text or execute a specific action for the command. A typical example of this command type is the provision of the factory-programmed settings of the DCE like manufacturer name, firmware version, etc.

Set command

A set command configures the preferred settings for the specified command. The set command is the only way to set the preferred settings in the DCE. For some commands it is possible to store the current settings in the profile or in the non volatile memory and retrieve them in another connection.

Read command

A read command provides the current setting of the command parameters. It is used to find out the current command configuration.

Test command

A test command provides the list of the values allowed by each parameter of the command.

Unsolicited Result Code (URC)

An unsolicited result code is a string message (provided by the DCE) that is not triggered as an information text response to a previous AT command and can be output, when enabled, at any time to inform the DTE of a specific event or status change.

The URC can have the same name of the command that enables it or can be enabled by another command. Generally the AT commands activate the URC on the present (virtual) AT interface on which they are enabled. If the AT commands settings are stored in the personal profile, the related URCs are enabled on all AT interface identifiers once set with AT&W (where supported). If the AT commands settings are stored to the NVM, at the module boot the related URCs are enabled on all the AT interfaces.

There are cases where both the AT command setting and the AT interface identifier is stored to NVM, therefore the URC will be enabled only on a specific AT interface. These cases are documented in the related AT commands descriptions.

For more details on the storing of AT command setting, see Storing of AT commands setting.

URCs presentation deferring

Since the URCs are text responses issued by the DCE without being requested by the DTE, their occurrence is completely uncorrelated to an AT command execution. Therefore, a collision between a URC and an AT command response might occur and it may lead the DTE to misunderstand the URC as part of the AT command’s text response or vice versa.

The module avoids this collision by delaying the URCs presentation if the AT command interface is busy. The AT command interface can be busy in the following cases:

  • During a data call (data mode)

  • During the execution of an AT command in command or online command mode

The command execution starts when the command line is completed by the command line termination character and the AT interpreter in the module accepts it; the command execution ends when the final result code for the command is sent out. Inside this period, the module is not allowed to send the not buffered URCs. For most of the messages, the DCE needs to be configured whether or not to send a URC. After enabling, for most of the URCs, if the AT command interface is busy, the pending URCs are buffered and their sending to the DCE is deferred. The RING indication is always generated as an unsolicited result code. The NO CARRIER indication is generated as an unsolicited result code when it has not to be considered the final response for the executing command (e.g.: ATH); if it is handled as an unsolicited result code, it follows the rule of the other URCs.

Generally, the buffered URCs are sent to the terminal as soon as the terminal exits the data mode or the command execution is terminated. An exception to this behavior is implemented for the following URCs classes:

ClassAT command to configure the class

Reception of a new SMS related URCs

+CNMI AT command

For the above classes, it is possible to select the presentation strategy when the AT interface is busy, according to the 3GPP TS 27.007 [9]; buffering or discarding are the two possible choices (URCs are lost in the latter case). This is done by means of the corresponding AT command (see the AT commands listed in the table above). If the URCs are enabled or, for the three described classes of URCs, the buffered URCs are sent out only when the AT interface is in idle again, then this occurs as soon as:

  • The data mode is released (the data call is disconnected)

  • The final result code for an AT command is issued

URCs presentation deferring and URCs caching can be configured with +UURCCFG AT command.

To ensure the DCE can transmit the buffered URCs, the DTE should wait some time (the recommended value is at least 20 ms) after the reception of an AT command final result code or URC before issuing a new AT command. Otherwise, the collision of the URCs with the subsequent AT command is possible.

If multiple AT interfaces are available, it is best to use one of the AT interfaces to manage all the user-enabled URCs, while using the other ones to send AT commands and receive their responses.

The URCs related to external causes (e.g., RING) are issued on all interfaces.

Intermediate Result Code (IRC)

An intermediate result code is a string message (provided by the DCE) which provides to the DTE some information about the processing status of the pending AT command.

Last updated: Jan 13, 2025
Need help?Contact Support
Questions?Contact us