Difference between PPP, QMI and AT commands

Question

During the past 6 days, I had the chance to interact with an LTE modem (https://sixfab.com/product/quectel-ec25-mini-pcle-4glte-module/), I managed to set up 4G Internet access on a Raspberry Pi using "QMI". But I still have A LOT of questions, I read many tutorials, articles and even articles from books but I'm still confused, I hope you have time to clarify things for me and for future readers:

• How do PPP, AT commands and QMI interact with each other and with LTE?
• What is the role of each of them? Do we need them all?
• Can you explain what happens (in details) when establishing a connection or rec/send data from the internet using these protocols? schemas will be great.
• I understand that PPP is used to connect the modem to the ISP, why do people say that it should be replaced by QMI?
• In this response https://unix.stackexchange.com/a/168690 we recommend using the wwan0 interface over tty for more speed, but all data shares the same only USB connection, right?
• if the max serial speed is 115200 bps, how do modems reach 150Mbps ? do they have buffers?
• According to https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA&LTE_Linux_USB_Driver_User_Guide_V1.8.pdf (page 8/47) the model provides many interfaces and they say that wwan* interface can be used as USB network adapter, what is the difference between wwan* and /dev/ttyUSB* ?
• Can you suggest some articles or books about that?

Solution

A LTE modem can be presented to the operating system in several ways. The legacy way is to emulate a legacy analog modem: in that case, the modem will present one serial (TTY) interface (/dev/ttyUSB0), which will be used for both modem commands & responses (AT commands) and data (PPP). In this case, when a network connection is established, the TTY device will pass a single PPP datastream, and the TCP/IP protocol packets are wrapped within PPP.

Having just one channel for both data and modem commands can be inconvenient: it makes it very tricky to send any commands to the modem (e.g. for monitoring radio signal strength) while the network connection is active.

There are higher serial port speeds than 115200 bps, and a USB-based serial port emulation might well report them. But if the actual connection is USB-based, the serial device emulation may just ignore some details of the emulation: for example, the serial port speed and the number of data and stop bits can be ignored, and the commands to set them can be made into no-ops. If necessary the commands to query those settings can be made to produce some sensible-looking answers... but those answers don't have to have anything to do with the actual transfer speeds. So a USB LTE modem in legacy mode may tell you that the /dev/ttyUSB0 is set to 115200 bps when queried, while the actual data transfer rate can be far higher.

The LTE radio protocol has native support of TCP/IP and IPv6, so there is no need to actually wrap TCP/IP into PPP over the radio interface. The PPP protocol is just used between the computer and the modem to make the connection look like a legacy dial-up modem-based network connection.

To get rid of the legacy cruft, newer ways to present USB-connected LTE modems like QMI and MBIM have been developed. QMI is a Qualcomm proprietary protocol, while I think MBIM protocol specification is the result of multi-vendor standardization efforts. They present the modem as a real network interface (typically wwan0 or similar) and an additional device (e.g. /dev/cdc-wdm0) for command access.

This cuts out the PPP layer, as the TCP/IP packets can be passed directly to the modem for transmission over the LTE radio protocols. It removes the need for both the computer and the modem to pretend that a venerable RS-232 serial port connection exists between them, while the actual connection is USB. And it allows a separate command channel that can be easily used to e.g. monitor the LTE signal strength, which may be important if the client device moves around while the network connection is in use.

Comments

[Steger]

Excellent answer!

[lucaswxp]

This is awesome! You should expand this and talk a little more about the additional device (e.g. /dev/cdc-wdm0) for command access and how it differs from ttyUSB