Give away medical masks when you place an order. learn more

Using Third-Party IP Protocol Stacks in M2M Designs



Instead of requiring developers to write new control code for each new IP protocol stack, Multi-Tech’s Universal IP is a single implementation that is applied uniformly across multiple modems that implement every major communications technology.

When TCP/IP functionality is employed in the embedded world, it is generally to enable machine-to-machine (M2M) communications. In many applications, such as fleet tracking and remote monitoring, the physical medium for the internet connection will be a cellular wireless network, but equally some embedded applications might access the internet via Wi-Fi or a wired Ethernet link.

The implementation of an internet-based M2M system will typically consist of, on one side, a chipset (baseband and transceiver) in which the baseband runs a version of the TCP/IP protocol stack; and on the other, an applications processor or microcontroller, which runs software to execute protocol commands via an applications programming interface (API).

Embedded developers are familiar with the pressure to reduce bill-of-materials cost and design risk on each individual project they work on. In the case of wireless internet-enabled systems, this can drive design teams to adopt an architecture that uses a cellular radio module (consisting of a cellular chipset, plus power circuitry and associated peripherals and interfaces), and to implement the protocol stack supplied by the chipset or module manufacturer. (Large chipset manufacturers include Qualcomm, ST-Ericsson Wireless and MediaTek. Module manufacturers include Cinterion and Sierra Wireless.)

When examined at the level of an individual project, this design approach might appear to make sense, but this conflicts with the common business model of small to medium-sized businesses (SMBs) in the embedded world. In reality, most embedded OEMs succeed by creating platform products on which they build extensions — product variants or modified versions of a base product — in three dimensions:

  • Over time — during the typically long product lifecycles of embedded devices, updated variants are periodically developed to adapt to changes in the technical, regulatory or user environment.
  • Over market segments — successful pioneer products in one market may be modified to suit the needs of adjacent markets. A fleet tracking device, for instance, might evolve a variant for container-tracking.
  • Over geographies — a European product could be adapted for the U.S. market by replacing a GSM capability with CDMA.

On this model, profitability depends on maintaining a stable core platform, and re-using as much application code as possible across every product variant. Now, the scenario for implementing a protocol stack described above begins to look flawed. The problem arises when a new product variant requires a new protocol stack implementation — and this can happen in all three dimensions:

  • Time — chipset manufacturers are driven by the short product lifecycles of handset manufacturers, not the large market windows that embedded OEMs address. Older chipsets are regularly made obsolete and replaced with new chipsets, and for each replacement the chipset supplier creates a new IP stack implementation.
  • Market segments — a low-end product extension might require a cost-reduction from a high-speed connection to a low-speed connection. Replacing a high-specification module with a lower-cost alternative might entail implementing a new IP stack.
  • Geographies — as above, different regions of the world run different cellular technologies. Replacing a GSM module with a CDMA module might again entail implementing a new cellular module with a new IP stack.

Each new IP stack will require developers to write new application code to control it. Development of this new application code potentially requires the designer to learn a new set of commands each time and to work out how to use a new API. Even if the embedded OEM uses the same module manufacturer across the whole of a product platform, the module manufacturer will not necessarily use the same chipset supplier across all modules. In any case, ensuring long-term consistency across all IP stack implementations is not a priority for the wireless chipset manufacturers, which are driven by the demands of the world’s top handset manufacturers, not by the collective demands of tens of thousands of small to medium-sized embedded OEMs.

Some module manufacturers have developed proprietary TCP/IP stacks to replace those supplied by their chipset suppliers, and in the long term this might enable them to align the different stacks that support different communications standards, such as 2G and 3G, under a single API.

But it is still the case that, for the typical embedded OEM, rewriting application code to interface to new IP protocol stacks is both difficult and fails to add extra value to the end product. It is difficult because of the nature of the typical embedded business. Development at these embedded SMBs is carried out by small design teams with expertise in the hardware and software aspects of their core application — design functions such as sensor interfacing, signal conditioning and processing, microcontroller or microprocessor programming, application development, and user interface design. Communications system design and configuration is a peripheral element of the design, and mastering its complexities is difficult to do when it is not the main focus of the team’s work.

The TCP/IP protocol stack implementations designed primarily for mobile handset OEMs are, then, ill-suited to the needs of many embedded SMBs. These SMBs would be better served by a stack implementation that allows re-use of application code across all product variants, and that makes the writing of this application code simple in the first place.

An architecture developed by embedded modem manufacturer Multi-Tech Systems is aimed at delivering this to low and medium-volume manufacturers. Multi-Tech’s Universal IP is a single implementation of the IP protocol stack that is applied uniformly across multiple modems which implement every major communications technology, from HSPA, GPRS, and CDMA to Wi-Fi and Ethernet. Universal IP implements protocols including DNS resolve, FTP client, Ping, POP3 client, PPP (dial-out), SMTP client, TCP RAW client and server, UDP RAW client and server, PAP and CHAP authentication, as well as various additional communications functions aimed at M2M applications (Figure 1).

Figure 1: Multi-Tech’s protocol stack implementation also supports additional functions aimed at M2M applications.

Each Universal IP modem also adopts the Universal Socket pinout (see Figure 2), which means that embedded developers can swap one modem for another without redesigning the board; they can also use the same application code to control the modem across all product variants.


Figure 2: Multi-Tech Systems implements the Universal Socket pinout across all SocketModem devices such as this SocketModem iCell intelligent embedded cellular modem.

Moreover, Multi-Tech is committed to maintaining a stable Universal IP API over the long term. This means, for instance, that OEMs can remain blind to underlying chipset changes. Just like embedded users of cellular modules, Multi-Tech has to periodically redesign its modems when a chipset goes obsolete, but users of Multi-Tech modems see no difference, because the Universal IP API always stays the same, as does the Universal Socket pinout.

The Universal IP stack implementation depends on the hardware architecture of the modems: in a cellular chipset, the IP stack is hosted on the baseband, which is the proprietary design of the chipset manufacturer. When the baseband changes, so does the IP stack, and users cannot control it.

In Multi-Tech’s Universal IP products, the protocol stack is hosted on a discrete processor, separate from the cellular chipset (see Figure 3). Since Multi-Tech has total control over the processor and the software it runs, it can ensure that its interface to the user’s system controller remains stable over time and over a complete range of modems. The result is that the interface between the application and the internet is always Universal IP, not the moving target presented by the module manufacturers.
Figure 3: Basic architecture of a typical cellular module and architecture of a Multi-Tech modem with Universal IP showing the discrete processor hosting the IP stack.

The stack communicates with the user system over a serial interface. The operation of the stack is controlled through a set of simple AT commands that will be familiar to anyone who has designed with modems. In fact, this suggests two meanings to the word ‘universal’ in Universal IP: universal across all modems that run the Universal IP stack, but also universally applicable by embedded designers, since any microcontroller with a serial interface can issue AT commands, and the AT instruction set is (at least almost) universally recognized by embedded developers.

The architecture of Universal IP products, with their discrete processor, also enables Multi-Tech to implement an IP stack with features suited to embedded users. For instance, Multi-Tech implements an Auto-Connect function in its Universal IP modems; should the device drop off the network, it will automatically attempt to re-connect without human intervention. The stack can also be configured to periodically input traffic to a cellular network (the Keep Alive function). Some cellular network providers automatically disable devices that have been idle for a certain period of time, a practice that might make sense for handsets but is inappropriate for embedded devices. This function ensures that the network sees that the modem is still active.

Conclusion

The mobile handset is the world’s highest-volume OEM market, and the cellular chipset business is therefore skewed towards the needs of fewer than 20 global manufacturers.

By abstracting the IP stack out of the chipset and into a processor under its own control, Multi-Tech’s Universal IP provides a way to address the application needs and product lifecycles of the thousands of embedded OEMs that need devices to access the internet via cellular networks or other media.
Supplier