How Different is Cellular from WiFi Embedded Design?

Embedded developers should know the differences between cellular and Wi-Fi types of connectivity, especially when moving from prototyping to production designs.

Is cellular connectivity more difficult to add to an embedded design that a WiFi connection? How does one move from a prototype design to a production ready device? To answer these questions and more, I talked with richardstamvik Segment Manager, Operator Relations at ARM. What follows is a portion of that interview. – JB

Blyler: How did cellular connectivity come to play in the embedded development space for applications like Machine-to-Machine (M2M) and Internet of Things (IoT)?

Stamvik: As a part of the segment marketing team, I help keep track of what’s going on in the cellular space. For us, segment marketing deals with customers beyond the silicon vendors, e.g., the device vendors, software developers, cellular operators, and such. This is important because the operators are the closest that we get to the consumers.

After the ARM mbed platform got going, the mobile network operators like Vodafone and Sprint realized that they would benefit by adding cellular connectivity into the embedded ecosystem. First, the operators would get access to a healthy, multifaceted, and occasionally headstrong (let’s say passionate) ecosystem of embedded systems developers.  These developers would be developing applications that would eventually come their way and generate traffic revenue in their network.

Vodafone started off by adding a USB dongle form factor modem with associated open source software onto the mbed.org website. That modem connected directly to an mbed board (see Figure 1), resulting in a prototyping environment that allowed for the rapid development of the conceptual design. Then Sprint followed suit and the rest is history.  Since then, other modular vendors have tapped into the mbed ecosystems abundance of developers and resources.

Figure 1: The Vodafone K3770 and K3772-Z modems allow you to connect your mbed platform to the Internet from (almost) any location in the world.

Blyler: Many embedded developers are uncertain how to incorporate cellular connectivity. Is it that much different from wireless interfaces like Bluetooth, Wi-Fi and the like?

Stamvik: From a conceptual point, “no”. But cellular networks tend to be more strictly controlled because operators are cautious about new devices joining their network without proper certification. All such things have to be certified by standard boards like the Global Certification Forum (GCF) in Europe and in Asia. The corresponding entity in the US is called the PTCRB. Most operators would like all devices to go through these standard body checks and they aren’t cheap. On top of that, each operator has his or her own verification processes. All of these requirements are meant to ensure that any device added to the operator’s network will not wreck that network. A cellular network crash is a catastrophic event.

Conversely, a device that wrecks a Wi-Fi wireless network is usually not catastrophic. You can reboot and off you go again. That is why cellular connectivity tends to be harder (than Wi-Fi). This is one reason why there aren’t that many cellular modem vendors while there are quite a few bluetooth and Wi-Fi modem vendors. Except for the toughness of the cellular standards, there isn’t much difference to the embedded developer. Cellular and Wi-Fi connectivity are both viewed as data pipelines, i.e., a communication channel from and analog-to-digital port.

Blyler: Can a developer by-pass the certification challenge by going with pre-certified subsystem? Wouldn’t that allow the developer to move more quickly from a prototype to a production ready system?

Stamvik: Certainly – that’s what usually happens. Developers add a pre-certified, self-contained modem like the Vodafone or Sprint USB dongle or the uBlox module.

Let’s talk about the productization issue (see Figure 2). mbed is a prototyping platform. A developer – say, an engineer at BMW – buys an mbed kit to design a device that will go into a future connected car. Once the prototype is functioning properly, he/she take it to his/her boss to get approval for the next stage, namely, turning the prototype into a product to be sold. Depending upon the particular design, that activity might require additional efforts to optimize the final product version for cost, power consumption, etc. But more often than not, the product version can be implemented using mbed’s existing tool suites, which means you can typically go from prototype to production with relative ease.

Figure 2: mbed Cellular Hardware Platform (courtesy of ARM).

Blyler: There is quite a difference between the prototype and the product process.

Stamvik: Indeed there is. The prototype is a functional or performance proof-of-concept. Meanwhile, the product is something you can sell.  Further, simply adding a pre-certified modem is fine for prototyping but may not be as easy when creating a product. At that stage, the developer might want to take a step back to decide the best way to optimize the overall design. They might go to the modular manufacturer or even the silicon chip manufactures for options. And the optimization process for power, performance or whatever cannot wreck the existing certification for the modem. The designer must be very careful if they open up the lid of a pre-certified modem and start fiddling with the internal pieces. You don’t want to break the certification.

Blyler: What’s the difference between a dongle and a module? Is one easier to productize then the other?

Stamvik: Consider the uBlox module that I mentioned earlier (see Figure 3). uBlox is a cellular modem vendor. But uBlox that the mbed board and platform as a marketing vehicle for their modem. That’s why they designed an mbed development board upon which to insert their cellular modem and offered it to the mbed ecosystem. In contrast, a developer would have to add a modem to  a standard development board that doesn’t already include wireless features.

Figure 3: uBlox module is an mbed board ready for cellular prototyping.

Blyler: In most embedded development projects, designers must do hardware and software trade-offs. Are there available power profiling and performance simulation tools?

Stamvik: Yes – There is a tool chain that comes in the mbed ecosystem. When you buy your board and hook it up to the website, you get access to the ecosystem, to the code repository with all the code that the thousands of developers have shared. Also, you get access to profiling tools, debuggers, compilers, etc. If you so wish, you can use your own stand-alone tools on your PC back home. But then you miss out on an excellent community that provides ready-made tools. And it is beneficial to use these tools for the prototyping phase.

However, when you want to go to product, you want to take a step back and use dedicated tools that might optimize for power, performance, size, price or whatever factors you have to take into account. The key is to reuse the technology that you’ve proven already.

Blyler: Should develops rush to incorporate more cellular connectivity into their designs?

Stamvik: In the IoT space, not all devices will be cellularly connected. The cellular vendors may wish that all of the coming 50 Billion devices will have 2G, 3G, or 4G connectivity, but that isn’t necessarily the case. There will be short range, Bluetooth, Zigbee, 6LowPAN and mesh networks. If Wi-Fi connectivity is needed, then there will be choices for fixed LAN connected things using Ethernet or proprietary cabling systems. Further, there will be interplay amongst all this different ways to connect. That is why we don’t have just cellular in the mbed system . There is an entire host of connectivity options.