Twilio’s Cellular Connectivity for IoT service is compatible with a wide range of devices from a variety of manufacturers. To help developers who are running into difficulties, we’ve collected a number of common configuration requirements, errata, and solutions to common challenges for many of the modules we’ve worked with in our lab. The list of devices will grow as our we and our developers work with more modems.
The presence (or absence) of a module in the Knowledgebase does not necessarily indicate a device’s suitability (or unsuitability) for use on our networks, and is provided solely as an aid to help developers with their implementations.
- nRF9160 (Cat-M1, NB-IoT)
- BG95-M3 (Cat-M1, NB-IoT, GSM)
- BG96 (Cat-M1, NB-IoT, GSM)
- EG21-G (Cat-1, GSM)
- EC25-A, EC25-G (Cat-4)
- EG91-NA (Cat-1)
- SIM7000G (Cat-M1, NB-IoT, GSM)
- SIM7080G (Cat-M1, NB-IoT, GSM) NEW
- SIM7600A (Cat-4)
- LARA-R203 (NA)/LARA-R211 (EU) (Cat-1/2/3)
- SARA-R410M (Cat-M1, NB-IoT)
While some configuration is specific to each modem manufacturer and sometimes each model, certain concepts behind getting connected with Super SIM are common to all modems.
Although the commands listed in this document should have similar parameters, outputs, and behavior across modules and manufacturers, please refer to the AT command documentation for your specific device(s) for parameter details and usage.
The Super SIM APN is
The APN is set on most modules this way:
The initial parameter is most commonly
1 but you may find some modules require it to be
0. With the APN set, you should be able to obtain an IP address from the network and to connect via PPP.
For more detailed guidance on setting the APN, particularly for devices with integrated modules, and for setting the APN using the Super SIM API’s SMS Commands functionality, please see our APN configuration page.
This APN is separate from the APN you may set on vendor-specific commands to utilize a modem’s built-in TCP, UDP, or application-specific protocols. This will vary by vendor and is described in subsequent documents for modules we have tested.
To get the best experience when using Super SIM with Cat-M1 modems, we suggest that you apply the following configuration settings on your device. They will make sure the Cat-M1 modem in your IoT device connects quickly and successfully. We’ve included examples showing you how to make these changes on popular Cat-M1 modems.
If your IoT device uses a regular LTE modem, the following changes do not apply.
Super SIM does not currently support Narrowband IoT (NB-IoT). If NB-IoT is enabled, a Cat-M1 device will scan all NB-IoT bands, which can take a considerable amount of time, before switching to Cat-M. To minimize the time to connect and avoid wasting power scanning NB-IoT bands, you should therefore disable NB-IoT.
Some modems support both Cat-M1 and 2G. If your modem supports 2G, we recommend that you disable it unless your IoT device can perform optimally on 2G, or Cat-M1 is not available where you will deploy your IoT device. There is a risk that if the initial connection is made over a cellular network (VPLMN) that does not support Cat-M1, your device will instead connect using 2G. It may then stay attached to the 2G network and may therefore be unable to receive over-the-air (OTA) updates from our platform. If 2G is disabled, then the device will only connect over a Cat-M1 network.
For Cat-M1 devices that don’t support 2G, this is not an issue.
We are actively exploring improvements to our mobile core to deliver OTA updates over 2G.
Even with 2G disabled, there are some instances where a Cat-M1 device with Super SIM can take up to five minutes to connect. This can occur when the first IMSI presented by the SIM to the modem doesn’t permit it to connect to a Cat-M1 capable network in a specific region. After five minutes of no service, the SIM will switch to another IMSI and the device should then be able to connect over Cat-M1.
There is an OTA campaign in process to update the preferred IMSIs for countries like the US and Australia. Once your SIM gets the OTA update, this issue will be fixed and the SIM will not take the extra time to connect on reboots.
To learn more about Super SIM IMSI switching, please see Super SIM: the Multi-IMSI Applet.
To check current operator status, use
This will return the current operator selection mode as well as your current operator, if any. For example:
Looking at the returned values from left to right, this result indicates automatic selection (
0) of the current operator (
2), which is T-Mobile (
"310260"), connected over 3G (
To list all of the operators visible to the module, issue
AT+COPS=? while the modem is attempting to connect to the network. The command will interrupt the modem’s normal scanning process and can delay connection to the network — it may take seconds or even minutes to complete. The modem will cycle through all supported radio access technologies to get all available networks.
Developers often use this command in conjunction with scanning for and manually selecting a network — this is not recommended for Twilio Super SIM.
In the output of
AT+COPS=?, you will receive a list of operators the modem sees. For example:
The values returned by this command, and by
AT+COPS?, will vary by your modem and the Radio Access Technologies (RATs) it supports. For the example above, we can see that:
- The modem was forbidden access (
3) to AT&T.
- The modem is currently connected (
2) to T-Mobile on 3G (the last
2in the section).
If you have used single-IMSI or fixed-provider SIMs in the past, you may be accustomed to selecting the operator by numeric or alphanumeric identifier. This is not generally recommended for Super SIM.
Super SIMs contain multiple IMSI from different network partners to give you access to the widest catalog of cellular networks. Each IMSI may have access to different networks in a country. We recommend that you enable as many networks as possible on your Fleet’s Network Access Profiles and leave your device set to automatic operator selection so that it will try multiple networks if it cannot connect on the first.
You can learn more about Super SIM’s multi-IMSI approach in this doc.
Manually selecting an operator obtaining a list of visible/available operators with
AT+COPS, or by manually de-registering from the network with
AT+COPS=2, can adversely affect connection times and even the ability to connect until the parameter is reverted. We therefore recommend always utilizing automatic operator selection using
You use Network Access Profiles to include or exclude specific networks you would like your device to favor or avoid. This is the recommended method you should use to steer devices to a particular network. If you must force the modem to connect to a specific network, typically for testing purposes only, you can manually select an operator using
AT+COPS=. For example:
Here we provide a desired network (AT&T,
310410) for the next connection attempt only, falling back to automatic network selection if it fails. If you prefer the device to remain disconnected if the connection attempt fails, replace the initial
If you need to reset the modem or disconnect for power reasons, we recommend using
AT+CFUN instead of
AT+COPS=2, which is a way to de-register from the network, tells the software running on Super SIM that the connected network was not suitable for the user. Super SIM will then have to exhaust all other possible networks, potentially with all available IMSI partners, until it loops back around to the functioning network again.
To terminate the connection to the network temporarily, use
To take the modem offline then bring it back, use
AT+CFUN=1. This applies the last known good network, for a quicker reconnection.
When working with a cellular module that supports both Cat-M1 and NB-IoT, it is important to restrict the modem to scan only for Cat-M1 networks. Super SIM does not support NB-IoT and scanning for NB-IoT along with Cat-M1 can result in a failure to attach in some locations.
Many modems use Unsolicited Response Codes (URCs) to communicate events and status changes to your application. These strings may not arrive on a serial line (UART, or Universal Asynchronous Receiver-Transmitter) your application is monitoring so check your modem’s documentation to learn how it will send URCs to your device and to find out how to change this if you need to. For those modems for which we have provided additional information, we will call out how to configure this feature.
Many commands which subscribe to URCs are scoped to the current session and will need to be sent again when the modem is next powered up or rebooted.
To obtain the current network registration status and to receive real-time connection state updates, you have a choice of three commands:
AT+CREGprovides the circuit-switched (CS) network connection status. CS connection notification is expected to occur before GPRS packet-switched (PS) connection notification.
AT+CGREGindicates the status of the PS network connection (e.g., GSM).
AT+CEREGindicates the status of the Evolved Packet System (EPS) network connection (e.g., LTE).
All three commands have several uses:
- You can explicitly query the modem’s current status with respect to each connection type:
- You can request URC notices of varying types for each:
- You can receive URCs from each, depending on your configuration.
All of these commands are scoped to the current session and will need to be sent again when the modem is next powered up or rebooted.
An effective way for your application to remain aware of the connectivity status is to register for the
AT+C[G/E]REG notifications most applicable to your use-case and therefore receive URCs relevant to that use-case. For example,
AT+CREG is good to use if your device is able to connect to the cellular network for voice and SMS, but will not necessarily be sufficient for data. For data communications, you should issue
AT+CGREG if your module supports GSM/EDGE and/or
AT+CEREG if your module supports LTE.
The output of
AT+C[G/E]REG and the URCs issued by the modem are directly affected by the modem’s URC setting. For example, if the command is set to return URCs with location information, the output will be augmented with a Location Area Code (LAC) and Cell Identification (CI), as well as the Radio Access Technology (RAT).
To request the status of the CS network connection, issue
AT+CREG?. An example response to this is:
- The inclusion of location and RAT in the response (
- Note The location information provides a coarse device location and should be treated sensitively.
- The device is registered as roaming (
- The LAC (
"0123") and CI (
"456789A") of the tower the device is connected to .
- The RAT in use is UTRAN/GSM (
If the setting of
AT+CREG=0 was applied, the LAC, CI, and RAT would be omitted. This applies to
AT+CEREG as well, depending on your modem’s capabilities and available networks.
To subscribe to terminal updates on status for these commands, issue one of the following:
AT+CREG=1to provide only registration status.
AT+CREG=2to provide registration status, location information, and RAT.
AT+CREG=0 to turn off receipt of network registration URCs.
These parameters may also apply to
AT+CEREG, depending on your equipment.
Once you have subscribed network registration URCs, the modem will issue notifications like:
The output is similar, but not identical, to the output of
AT+CREG?, above. The URC will omit the current setting for the command (
2, in this case).
Registration URCs will come in for a variety of reasons:
- When the modem is rejected from the network (no connection).
- When the modem is registered to the network (no connection yet, but one may be possible).
- When the modem moves between cells without an interruption in registration (connection may be active but is not interrupted).
As a result of the last item, when the modem moves between cells, you may see numerous
CREG indications over the course of a connection without your data session being affected.
A number of standard informational commands exist that may be useful to your application or when troubleshooting connectivity. Some of the most common commands are listed below. More information on these and other manufacturer-specific commands can be found either in our manufacturer and modem specific documentation or the AT command guides for your specific modem.
- Retrieve the modem’s International Mobile Equipment Identity (IMEI):
- Retrieve the SIM card’s Integrated Circuit Card ID (ICCID):
- Retrieve the SIM card’s ‘current’ International Mobile Subscriber Identity (IMSI):
- Note ‘Current’ relates to Super SIM, since the Super SIM has multiple IMSIs assigned. Programmable Wireless SIMs have a single static IMSI.
- Retrieve the modem’s manufacturer:
- Retrieve the modem’s model:
- Retrieve the modem’s revision:
While these commands are generally standard on cellular modems, the output and contents may vary between manufacturers.
This is discussed separately, on this page.
Developers who have moved to Twilio from another wireless connectivity provider often reset the modem and apply a short timer (e.g., five minutes or less) to get back online. This can be effective for single-IMSI SIMs, which scan for a very specific network when the modem is back up.
This can be detrimental to Super SIM’s ability to connect and is not recommended. Each Super SIM contains software which is also trying to pivot and reset the SIM’s connectivity while it is trying to reconnect. If your application is resetting the modem more frequently than the built-in timer is pivoting to other connectivity options, the Super SIM may never have time to switch networks. This can also negatively impact the Super SIM’s ability to receive important connectivity updates from Twilio.
We recommend that any application-based timer have a cycle of at least 10 minutes to ensure that the Super SIM has time to connect if it is needed. If 10 minutes is impractical for your application for every reset, you can configure logic that allows for an occasional/periodic 10-minute span followed by a number of shorter intervals.