You’ve probably heard of QMI, but what about MBIM? And what was the story behind ECM? Is serial a driver? Or an interface? A lot of abbreviations to keep track on in the cellular arena nowadays, especially with both legacy drivers and interfaces, as well as (relatively) new ones. Read next and learn more about the interfaces we all love (and hate)!
ECM, NDIS, RNDIS, MBIM, RMNET, QMI… what are all these abbreviations? These are all drivers, sorry, they are protocols. Wait… which one was which now again? Let’s take a deep breath and go through all this thoroughly…
All of these are ways of communicating between the computer and the module, they are frequently appearing and are standardized in some way or another. Drivers are unique for each OS, and some drivers appear more frequently in one OS than the other, which makes it difficult to gather a clear overview.
How do drivers differ from protocols then? An easy way to understand this is to see the driver as the tunnel between the module and the computer, it is what makes it possible to communicate and send information back and forth. The driver tells the specific OS how communication should take place through the tunnel. While the protocol describe in what way communication should take place following a set of rules, independent of the OS. To summarize, protocols define the rules for communication, while drivers implement these rules and handle hardware-specific interactions. But for now, we can consider driver as the collective word.
Before we start talking about specific drivers, we need to understand that there are different kinds of drivers that have different use cases. The two most used categories for network modules are Serial drivers, and Network drivers:
- Serial drivers originate from the RS-232 electrical interface (COM Ports), which back in the day were used for a variety of things like modems, mice, terminals and more. When the modules switched over to the physical USB interface, the RS-232 interface was not used anymore. However, the way of communicating bit by bit is still widely used either through other physical interfaces or virtually over physical interfaces such as USB. Today it is used for sending AT commands to the module from the computer, for diagnostics (DIAG Port), GPS streaming (GNSS) and more.
- Network drivers are responsible for the IP data flowing over USB which is exposed as network interfaces such as usb0, wwan0, eth1, etc.
A typical cellular module use more than one driver for different purposes. It has different so called interface endpoints, where one driver is assigned to each endpoint (see it as multiple tunnels). These endpoints stem from the hardware on the module. See the example below:
The arrangement of the interface endpoints is called a USB Composition, which represents the order of use cases for each endpoint. The composition is defined by the modules firmware, which describes how the USB interfaces should be exposed to the host. In this example the DIAG endpoint utilize serial communication, which then would require a serial driver, same goes for the NMEA (GPS) and AT endpoint. RNDIS which represent the network communication would require a network driver.
We mentioned frameworks before, and you might have encountered the letters” CDC” before, it is used as a sort of prefix, e.g CDC-ECM, CDC-NCM, CDC-ACM etc. CDC stands for” Communication Device Class” which is a standardized framework for how communicating (network) USB devices should present themselves and send data to the host computer, brought forward by the USB Implementers Forum (USB-IF). The framework was developed along with the release of the Universal Serial Bus, which is the physical interface we all call USB. These CDC-ECM, CDC-NCM, etc are built upon the CDC-framework and are subclasses to CDC. Subclasses are not any piece or software or hardware; it is simply documented guidelines on how communication should take place in different cases. And it is from these subclasses that protocols are made. A lot of words right now, but here is a mind map:
Now let’s go over some subclasses:
CDC-ACM (Abstract Control Model) emulates serial ports over USB, mostly virtual COM ports. Linux follow the subclass structure with its driver cdc_acm.
CDC-ECM (Ethernet Control Model) determine how ethernet frames are transported over USB. Linux adhere to this subclass with its driver cdc_ether.
CDC-EEM (Ethernet Emulation Model) is similar to CDC-ECM but with more efficient framing. Linux is also here following the subclass with the driver cdc_eem.
CDC-NCM (Network Control Model) similar to both ECM and EEM but with more complex framing that allow for better performance. Yes, you guessed it, Linux does in fact have a driver for the NCM subclass also, called cdc_ncm.
CDC-MBIM (Mobile Broadband Interface Model) defined an interface for cellular modules specifically, offering a wide support for mobile broadband devices. One of which were IP packets being transferred directly over USB while ECM, EEM and NCM send encapsulated ethernet frames, containing more overhead. And as you probably discovered Linux is the OS that is better at following and making use of the CDC subclasses, compared to Windows. But this is the exception, where Windows have been playing a significant role to implement MBIM into their OS, with their driver named just MBIM. But of course Linux did not miss the opportunity to also follow CDC, with their driver cdc_mbim, because Linux loves CDC-subclasses. Worth to mention here however is that Windows MBIM does not only count as a CDC subclass, as CDC is specific for USB. The Windows driver is broader and does work for other interfaces such as PCIe, while the Linux cdc_mbim driver is exclusively made for USB, which makes the Linux driver count as a pure CDC-subclass driver.
And it is not only the CDC subclasses where Windows and Linux differ, there will be more deviations from one and another. Both how they make use of different sets of drivers, but also how drivers tie to module endpoints as discussed earlier. Let’s go over this.
Linux drivers contain a large amount of module IDs within its drivers in the kernel, more specifically there are two IDs that are VID (Vendor ID) and PID (Product ID). They work like expected, there is one ID for the vendor, and one for the specific module, these are sent over to the OS as soon as the module is connected. Along with VID and PID, the interface endpoint is also stated in the kernel-file. Linux then go over the IDs and match the correct driver to the correct endpoint. After assigning drivers the OS start creating device nodes. As for the serial endpoints there are nodes (files) exposed in the /dev folder, such as /dev/ttyUSB* (fun fact: tty stands for teletypewriter, due to early terminals being connected with electric teleprinters AKA teletypewriters, the name is kept for text-only consoles in Linux). The serial nodes are used for different functionalities, commonly for sending AT commands. The OS also create nodes for the network endpoints, such as wwan0. There are also nodes exposed that are control interfaces, which is relevant for MBIM and QMI supported modules, this exposed node is /dev/cdc-wdm0, which corresponds to the endpoint that would use the qmi_wwan driver or cdc_mbim. The cdc-wdm0 node makes is possible to configure the module with user-space utilities such as libqmi and libmbim. In conclusion, VID, PID and interfaces are sent over, drivers are assigned, device nodes are exposed for different interactive use-cases.
Windows works in a different way than Linux, but also here VID and PID is relevant, instead of matching the IDs with specific driver-files in the kernel it matches them towards drivers INF-files (installation scripts). Based on the INF file windows install drivers towards the correct interface endpoints. For serial endpoints virtual COM-ports are created that allow for use such as sending AT-commands. For network endpoints windows initialize appropriate drivers such as MBIM or RNDIS, instead of appearing as a COM-port this endpoint is placed in a network adapter category. The categories can be seen in the windows device manager. After this the user-space tools can interact with and configure the modules.
Now that we have cleared up what a driver is used for, what type of drivers exist and how they are initialized between the module and OS, we can start looking at common specific drivers and how they appeared over time.
One of the earliest drivers were the windows NDIS driver that came along with the Windows 95 release back in 1995. NDIS was made for communication between network hardware and the OS, support for miniports allowed for use with NICs and its data transmission. The NDIS driver could not be used over USB which the RNDIS driver came to solve later year 2001, with the release of Windows XP. Now USB connected devices could show up as network interfaces to the host system. Today RNDIS is much more commonly used than NDIS, which makes sense as it is built upon NDIS. Later MBIM was released 2012 along with Windows 8, providing a widely tailored support for mobile broadband devices with several significant changes. Transferring IP packets over USB where other drivers sent encapsulated ethernet frames. Also support for 5G, USSD, SMS, SIM toolkit functionalities and more.
Meanwhile Linux developers are implementing drivers, as for the CDC framework mentioned before, cdc-acm was created in 2005, cdc_ether (CDC-ECM) in 2007, cdc_eem 2009 and cdc_ncm in 2010. But during this period other drivers such as the equivalent of Windows RNDIS came out in 2005, named rndis_host.
The commonly used driver usb-serial was made in 2005, compared to cdc-acm it allowed for USB to-serial conversion exposing ttyUSB* nodes instead of ttyACM*. Another serial driver option was created in 2009, and as we have mentioned how Linux detect what drivers are to be connected to what endpoint-interface, the option driver has the ability to connect multiple different drivers to specific endpoints, since a large amount of VID/PIDs are specified in the kernel, whereas usb-serial has a more generic and broad approach to expose multiple endpoints to one exposed device node. The last serial driver we will mention is qcserial which is a Qualcomm-specific driver made for modules with Qualcomm-chipsets, having chip-specific features that option does not provide.
Back to network drivers then! In 2012 Linux devs implemented the cdc_mbim driver. And lastly, probably the most commonly used network driver was released in 2012, qmi_wwan tailored for modules using Qualcomm chipsets, which pretty much is every network module that is used today. Since this is one of the most common drivers we’ll go a bit more into detail here, particularly for Linux as Windows normally do not use QMI (only when configured to use vendor-specific drivers). When talking about QMI there is another term we need to be familiar with, which is RMNET. QMI and RMNET go hand in hand, but what is the difference between the two? QMI (qmi_wwan) exposes the control interface /dev/cdc-wdm0 for sending communication via user-space tools, in this case libqmi. This tool makes it possible to configure the module without sending AT commands (even though it is still available on another interface endpoint). QMI also expose the network interface, along with registering different kinds of network communications called PDNs (Packet Data Networks). PDNs are the different kinds of network connections the module can handle such as normal Internet, IMS, MMS (each with distinct IP settings). Here is where RMNET comes into the picture, is works with the data transfer, by exposing interfaces named rmnet0, rmnet1, etc… the different interfaces correspond to each PDN. Using multiplexing RMNET sends MAP packets over the single internet interface e.g wwan0. MAP (Multiplexing and Aggregation Protocol) encapsule the different packets with a header containing an id making sure it arrives at the correct rmnet interface/PDN. All this allows for faster data rates by using only one network interface for data transmission, instead of having one stream of data per PDN. Below is a visual concept map:
Here is a summary of the mentioned drivers:
But these are not the only drives, these are some of most common network drivers already existing within the OSes. There are several more drivers for certain cases, vendor-specific drivers, etc. As the title suggest, this is just an overview. And let’s not forget about Wi-Fi-drivers, but that is for another blog-post!
Good luck with navigating the driver-djungle and finding what works for your network modules, hope this gave you a broader overall understanding and helped you along the way! And please remember – 524WiFi can help you to get the right driver for your application!