Cellular modem API development

[bjarki-andreasen]

Introduction

We need a device driver API to configure and control cellular modems. This RFC will list every individual feature the API should cover, documenting the requirements and rationale behind every individual feature. This RFC will then be used to track the development of each individual features development, which should be in large part developed in parallel driven by a variation of developers.

Cellular modem API progress overview

The following tasks indicate whether a feature has been successfully implemented or not.

• Setting network credentials (PIN, PUK, APN, ...)
• Getting network signal quality
• Getting network status (searching, registered, roaming)
• Setting radio access technologies (LTE, NB-IOT, used bands, ...)
• Getting supported radio access technologies and bands
• Getting modem properties (IMEI, IMSI)
• Configuring power saving
• Asynchronous Event Callbacks

Cellular modem API documentation

Each individual feature is described in detail here

Setting network credentials

Assignee: Unassigned
PR: None

Getting network signal quality

Assignee: @ldenefle
PR: #65685

Getting network status

Assignee:
PR: #67025

Setting radio access technologies

Assignee: @bjarki-trackunit
PR: #64537

Getting supported radio access technologies and bands

Assignee: @bjarki-trackunit
PR: #64537

Getting modem properties

Assignee: @ldenefle
PR: #65685

Status summary

The RFC is at this point only an initial proposal to which features we should implement, and what they should cover. Everything is open to change, and no actual work has begun.

The first step will be to discuss which features we should to cover to which degree :)

[jeffwelder-ellenbytech]

Looking forward to these improvements! :)

I'm interested in switching firmwares using the AT#FWSWITCH command for use with eSIM. In the USA there's often multiple carrier firmwares in a modem for different provider requirements: (AT&T/Verizon/Global)
Maybe this would be part of Setting Radio Access Technologies, or maybe a new category is more appropriate.

Probably could find some time to work on it once something is defined, or with some guidance.

Also maybe a category for HW Settings such as Flow Control, Baud, etc.

[naNEQ]

Very much looking forward to that and willing to help.

Small input from my side, in the "Getting modem properties" part, I think these should be included:

• Modem IMEI (AT+CGSN)
• Modem ID (AT+CGMM)
• Modem manufacturer (AT+CGMI)
• Modem FW version (AT+CGMR)
• SIM card IMSI (AT+CIMI)
• SIM card ICCID (AT+QCCID)

[JordanYates]

Is there any appetite for pulling this functionality under an equivalent to the wifi_mgmt.h API?

For example, to me a single NET_EVENT_WIFI_CMD_IFACE_STATUS call which returns a struct wifi_iface_status is a nicer model than individually calling a host of functions, as currently defined in the cellular.h API.

It has the additional benefit of being an existing API that is proven and easily extensible.

[beriberikix]

Personally I think adopting something like this functionality for Wi-Fi would be a nice benefit. There's different protocols (ex. custom AT cmds), interfaces (SPI/UART/SDIO/USB), features (ex. co-existence) that may be similar across wi-fi vendors but are subtly different.