Lanedo has been involved in the development of ModemManager and related modem/networking technologies on GNU/Linux for several years now, and we have been improving it lately to support several new features required on Google’s Chrome OS platform, where ModemManager is the subsystem managing mobile broadband devices and their connections. These new features only apply to modems with the 3GPP2 variants of Qualcomm Gobi (Gobi 2k, Gobi 3k…) chipsets, which include devices from multiple manufacturers like Pantech, Sierra Wireless or Qualcomm itself. The Gobi devices do expose an AT-based status and control interface, but they are designed to be managed using the QMI protocol (e.g. through libqmi, a Free Software library Lanedo wrote and maintain with QMI specifically in mind).
3GPP, 3GPP2 and ModemManager
There are two main associations pushing standards for mobile broadband connections nowadays: 3GPP and 3GPP2. Although the acronyms might suggest that 3GPP2 is an evolution of 3GPP, these two associations are actually completely different and independent. 3GPP is the one behind the standards used in most countries (GSM, GPRS, EDGE UMTS, HSPA, LTE…) while 3GPP2 is behind several standards which are used in the US, India, China, Japan and South Korea (CDMA1x, EV-DO, UMB…). But this is not a hard rule, as those countries using 3GPP2 standards also use 3GPP ones as well, in particular since LTE, which is defined by 3GPP, is the 4G technology of choice everywhere (UMB, the 3GPP2 counterpart for 4G, was halted in late 2008).
CDMA1x and EV-DO devices are still used extensively in those countries implementing 3GPP2 standards, and they have a lot of differences with respect to the more common 3GPP broadband modems. In ModemManager we have supported 3GPP2 devices since the very beginning, but just for the most common features like network registration and connection setup, while leaving most of the side features unimplemented.
Some of these side features have now regained importance, and we have been working closely with Google to integrate them properly in ModemManager. All in all, the management of 3GPP2 devices has improved a lot lately, and (most of) the improvements are already integrated in git master ready for a future 1.2 release.
It’s worth noting, that while the new DBus interfaces implemented are generic, they will currently only be exposed for 3GPP2 devices which use the QMI protocol.
3GPP2 device activation
Unlike 3GPP devices, most 3GPP2 devices don’t need a SIM card to work. Instead, they need to be activated with the 3GPP2 network. The activation process depends directly on the specific network operator, so for example, Verizon and Sprint (network operators in the US) both require different activation processes. During this process, which is a one time operation, the subscriber information is written in non-volatile memory on the device. Among others, the activation process will handle the following parameters:
- SID: The System Identification Number, which uniquely identifies the network (think of MCCMNC in 3GPP devices).
- MDN: The Mobile Directory Number, which uniquely identifies the subscriber of the service (think of IMSI in 3GPP devices)
- MIN: The Mobile Identification Number, which is derived from the MDN.
- PRL: The Preferred Roaming List, which helps to identify when the device is attached to a roaming network
ModemManager now supports both the Manual and Automatic activation processes, which help to configure the previously listed parameters.
Using manual activation, the user can specify the service provisioning information, without requiring the device to be attached to a network. ModemManager allows this operation with the ActivateManual() method in the org.freedesktop.ModemManager1.Modem.ModemCdma interface.
The ModemManager command line interface (mmcli) was also extended to support this operation, e.g. (using dummy numbers):
sudo mmcli \ -m 0 \ --cdma-activate-manual="spc=000,sid=123,mdn=456,min=789" \ --cdma-activate-manual-with-prl=/path/to/prl.file
Note that the manual activation process requires the user to provide a valid SPC, the Service Programming Code, which is an operator-specific number required to perform the process.
ModemManager can request OTASP-based activation using the ActivateAutomatic() method in the org.freedesktop.ModemManager1.Modem.ModemCdma interface. This method requires a ‘carrier-code’ number as input, which is an operator-specific number that will be dialled during the process (e.g. *228 for Verizon).
sudo mmcli -m 0 --cdma-activate="*228"
OMA device management
The Open Mobile Alliance (OMA) has defined a device management protocol (OMA-DM), which among others, allows the device to perform updates of the PRL in 3GPP2 devices (e.g. if the device was manually activated without specifying a PRL).
This device management protocol is managed by ModemManager with a new org.freedesktop.ModemManager1.Modem.Oma interface, which allows the user to either initiate a DM session, or to accept/reject a network-initiated DM session, e.g.:
sudo mmcli -m 0 --oma-start-client-initiated-session="client-initiated-prl-update"
In addition to user-initiated and network-initiated session, the OMA support in the modem also allows for automatic device-initiated device management sessions, which are handled without any user intervention.
3GPP2 SMS messaging
CDMA1x and EV-DO devices support SMS messaging, but this service is not as widespread as in GSM/HSPA networks, mainly because messaging does not come by default with your subscription. If you want SMS messaging, you need to request the operator to include this in your subscription, which potentially increases its price. Nowadays, where most messaging in mobile devices is done through basic IP-based communication, SMS messages are less and less critical. However, there are still fully valid use cases, where you want to get messages even if there is no IP connection setup: think of the SMS you receive in foreign countries explaining that you’re roaming and stating the new cost of the calls; or the SMS-based money transfer operations in developing countries; or the alerts issued by governments/operators when there are life threatening events around you (e.g. ETWS).
3GPP2 SMS messages are not encoded in the same way as 3GPP SMS messages. 3GPP messages are encoded based on the “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS)” (3GPP TS 23.040); while 3GPP2 messages are encoded based on the “Short Message Service (SMS) for Wideband Spread Spectrum Systems” (3GPP2 C.S0015). The biggest difference between both formats, I would say, is that the 3GPP SMS format is merely a container of data (either text or binary data) with very little metadata on what the SMS actually contains; while the 3GPP2 SMS format puts a lot of effort in defining what the actual contents are about. For example, 3GPP2 SMS messages define different “teleservices” (e.g. messaging, paging, or voice mail notifications…) and “service categories” (e.g. emergency broadcasts, news, weather reports, advertisements…). The actual text content of the SMS is therefore given in the context of the specific teleservice and service category.
Basic 3GPP2 SMS support has been implemented in ModemManager by extending the already existing org.freedesktop.ModemManager1.Sms interface with two new TeleserviceId and ServiceCategory properties. In addition to this, the QMI-based implementation now looks for both 3GPP and 3GPP2 SMS messages, and will decide which one to create based on the input parameters passed by the user. We are not exposing in our interfaces all possible fields that the 3GPP2 SMS may have, though, just the most important ones plus the ones we already had equivalents for in 3GPP SMS.
Supporting 3GPP2 SMS messages in non-QMI AT-based modems shouldn’t be a big issue now, specially because they usually use the same set of AT commands as for 3GPP messages, but using the 3GPP2 specific encoded messages; and because parsing and creating these is already implemented for QMI-based ones.
This support for 3GPP2 SMS messaging is not yet in ModemManager git master, as further tests need to be done. If you happen to have a Gobi 2k/3k/4k modem using CDMA/EV-DO networks and you also have SMS functionality enabled in your subscription, please do grab the ‘aleksander/cdma-sms‘ branch from upstream ModemManager git repository and test! 🙂
Is that all?
Of course not, no 🙂 Mobile broadband modems are not just ‘modems’ any more; they come with a huge set of new features, and ModemManager currently just handles the most common ones. If you ever end up requiring new functionality in ModemManager or networking on Linux-based systems, read more about our experience or get in touch and see how we can help you!