ciot modem gsm nb-iot lte-m atcommands saran2 nrf91 bg95

Cellular IoT basics

If you’ve never used any kind of cellular connectivity or cellular IoT communication it’s not entirely clear how, what and why things are done the way they are. If anything the telco business is ripe with acronyms and by the time you’ve read the first few introductory pages you are probably even more confused.

Conceptually the whole setup is quite simple:

flowchart LR D["Your Device"] N["Mobile Network"] I["The Internet"] D-->N N-->I

The device side

Let’s start at point A. Your device will need two things to connect: A cellular IoT module and a SIM card. The SIM card you’ll need are a standard SIM card but it will some kind of IoT subscription. Technically the SIM card and subscription works just like your mobile phone subscription but it is very unlikely you’ll ever going to call to your device or call someone from the device so the phone number on that subscription is something you can safely ignore.

The SIM itself has multiple identifiers but the one we’re interested in is the IMSI number. This is the number that identifies the SIM card on the mobile network. SIM cards come in several different shapes and form factors. It might be a simple card like the one in your mobile phone and these come in several standard form factors; from 1FF - the credit card-sized first SIMs through to 2FF (used in old Nokias), 3FF (early iPhones) to 4FF which just about every single phone uses today. You can also get a SIM card on a chip and they are called MFF2 and eSIMs which are embedded in another chip entirely.

The SIM card is attached to a module which takes care of the nitty gritty details of connecting to the mobile network. There are several alternatives here, from the all-in-one nRF91 from Nordic Semiconductor to separate modules from uBlox …and several others.

The hardware itself is identified with the IMEI number. This number is used for all kinds of things connected to the mobile network. You will sometimes see this referred to as “User Equipment” (UE) or “User Terminal” (UT). Your phone has an IMEI number as well - press *#06# on the keypad to see it.

The most common approach is to use AT commands on an UART to communicate with the module. There are no standard AT commands to set up a connection so what commands you’ll have to use depends on the chipset and vendor. If you use the nRF91 from Nordic you can use both regular BSD sockets to manage the connections and an API to manage the modem.

flowchart LR D["Your Device"] N["Mobile Network"] I["The Internet"] subgraph Modem direction TB M["Module"]<-->S["SIM Card"] end D-->Modem Modem-->N N-->I

If you dig around in the various AT command sets you’ll see IP addresses popping up once in a while. Internally in the mobile network the module data is moved across an IP network. This bit is handled on the Internet-side of the network.

The Internet side

On the Internet-side of the mobile network there’s the (slightly unfortunate named) APN aka the “Access Point Name”. This is a link from inside the mobile network to the outside. The APN isn’t the only thing that makes this happen but it’s common to refer to it as just “the APN”. In reality there’s a packet gateway (or “PGW”) on the mobile network side that routes the data (and connections) between the mobile network and the Internet. On the Internet side there’s a service that assigns addresses (the same address you’ll see if you run the AT+CGPADDR command on the module).

The APN to use can be set by the module (connected to your device) or you can just leave it as-is and get the default setup for your particular SIM card.

With regular data connections (for example when you are surfing on your mobile phone) your SIM card is assigned to the public APN. This is a common access point for all devices on the mobile network. It is possible to host your own access point and manage the devices but in most cases you want to use a ready-made one, at least for the initial testing and development.

The setup looks like this:

flowchart LR D["Your Device"] I["The Internet"] subgraph Modem direction TB M["Module"]<-->S["SIM Card"] end subgraph Network direction TB N["Mobile Network"]-->PGW PGW-->APN end D-->Modem Modem-->Network Network-->I

The Span service slots in between the Internet and the PGW like so:

flowchart LR D["Your Device"] I["The Internet"] S["Span"] subgraph Modem direction TB M["Module"]<-->C["SIM Card"] end subgraph Network direction TB N["Mobile Network"]-->PGW PGW-->APN end D-->Modem Modem-->Network Network-->S S-->I

In reality you only have to relate to the modem and Span - the mobile network itself is transparent:

flowchart LR D["Your Device"] I["The Internet"] S["Span"] D-->Modem Modem-->S S-->I

When you register a device in Span with the appropriate IMSI and IMEI numbers it will detect when your device connects, assign it an unique IP address and keep track of the data that your device sends. From there on we can forward the data (to point B), keep a backlog of messages and group the devices into collections to ease management.

If you use nRF91 the whole process is a bit more transparent. You select the APN in a configuration file with CONFIG_PDN_DEFAULT_APN="mda.lab5e" then set up the connection just like a regular BSD socket to get connected. From the firmware’s point of view it’s similar to programming on a desktop computer.

You could use the public APN to send data as well but you’d have to encrypt it and add identifying information on each packet and keep track of configuration changes on the Internet, f.e. when your backend changes its IP address or moves to a new location.

Where do I start?

If you are just starting out with cellular IoT and have just got a new module I’d recommend getting a serial terminal up and running and connect to just the module. Fiddle around with commands and make sure the module gets online. Step one is to always run the AT command. If the module responds with OK you have a working connection with the correct baud rate. Most of the time I end up connecting the RX and TX pins the wrong way around (some label the RX pin TX so that you connect TX-TX and RX-RX while most use TX-RX and RX-TX).

Next you can try running AT+CGPADDR to see if the module is online and has gotten an IP address. It should report what address you have.

Finally, if you are going to use AT commands to send and receive data you can make a few manual attempts to send data and make sure it arrives in Span. The commands to set up and send data on the socket varies between modules but for SARA N2 and N3 modules it’s these commands (this will send “hello world” to Span):

AT+NSOCR="DGRAM",17,30000,1
AT+NSOST=0,"172.16.15.14",1234,12,"48656C6C6F20576F726C6421"
AT+NSOCL=0

nRF91 with the serial LTE modem app uses these commands:

AT#XSOCKET=1,2,0
AT#XSENDTO="172.16.15.14",1234,0,"48656C6C6F20576F726C6421"
AT#XSOCKET=0

A Quectel BG95 module uses these commands:

AT+QIOPEN=1,1,"UDP SERVICE","0.0.0.0",0,0
AT+QISEND=1,12,"48656C6C6F20576F726C6421",1234
AT+QICLOSE=1

…as always - these might be subject to change so check out the relevant AT commands manual for your module.