We dubbed the last installment of D2D “The Retro Issue” because it looked at the revival of a number of technologies well beyond their hype curve. We looked at Location Based Services and Ad Hoc networks, but we forgot the Grandaddy of them all – Machine to Machine Comunications (M2M). M2M and its close cousin RFID have been receipients of immense industry hope for well over a decade. This has perpetually been the technology whose glory days are just over the horizon. Knowing this, we still think that conditions are slowly reaching the point where M2M is starting to show signs of real commercializtion. That day has not arrived yet, but more and more of the pieces are coming into place.

What is M2M?

When you make a voice call, you are a person commuicating with another person. When you surf the web you a person communicating with a machine (i.e. some web server somewhere). As the name implies, Machine to Machine communications closes that loop and has some machine communicate with some other machine. The idea is that some remote piece of electronics, like a temperature sensor, communicates with a web server or database. No humans involved.

The idea has obvious appeal. The prototypical example is wiring up all the Coca-Cola vending machines so that they can send an alert to the warehouse when they are running low on Coke Zero. Or an oil field with pressure sensors scattered over a vast area which can report conditions back to the command center.

To date, the largest M2M deployments are “Smart Meters” with which the power utilities have replaced human meter readers. So far, most M2M deployments have tended to be highly customized, something that only very large companies can build.

Custom to Common

The allure of M2M is built on two factors. One, the cost of a radio needed to connect some sensor to the core network is now very cheap. Estimates vary, but in theory modules could cost $15 for 2G to $100 for LTE, and with time could be much lower. After all, you can buy a perfectly reasonable feature phone for $20, and an M2M module can be much simpler.

The second piece of the allure is that the amount of data sent from each remote endpoint is typically very low, a few hundred bytes at most, just a sensor reading or an on/off signal. And this traffic is highly predictable. This makes building the necessary cellular network relatively easy. In theory, users can schedule endpoint transmissions to occur in off-hours, further reducing the load on the network.

Unfortunately, there are a host of other problems. From a high level, this is a common problem in wireless. Focus tends to rest on the physical layer, the radio connection between some device and the core network. The allures we detailed above reflect that. However, in this case, there are numerous other considerations:

• Connecting to carrier networks that were not built for this
• The wide range of use cases requires considerable, expensive embedded programming
• What do you do with all that data once you collect it?
• Attaching the M2M radio to real-world equipment, how do you retrofit?

Carrier Networks

Mobile networks were originally built for phones. The transition away from this thinking is still playing out, with most voice calls today still handled as circuit-switched connections at some level, as opposed to packet-switched networks of the Internet age. In this case, most M2M endpoints needed to have ‘phone numbers’ assigned to them. Each data session needed to be set up, maintained and then disconnected. Invisible to users, this process is handled by ‘signaling’ networks that sit alongside the networks which carry traffic. In many cases, the M2M data is much, much less than the amount of signaling traffic required for a basic data transmission. Think of the time it takes to dial a phone, wait for someone to pick up. If you just say one word “Buy” and then hang up, you get a sense of the overheads involved in M2M communications

Originally, carriers hoped to use their legacy 2G networks to handle M2M traffic and move voice customers to 3G and 4G networks. Unfortunately, the 2G networks are the most circuit-oriented and this signaling penalty made those plans unfeasible. Today, the thinking is increasingly towards using 4G LTE networks for M2M connections as these are entirely packet-switched.

Nonetheless, the carriers are still unclear about how to handle M2M networks. In the US, AT&T and Verizon have acquired, invested in and/or partnered with dedicated M2M service providers. These companies, such as nPhase, provide an overlay of sorts, that are plugged into the carriers’ networks but offer up much simpler interfaces to M2M end-users.  Working with the carriers has gotten easier, but a lot of integration work remains.

And then there is pricing. Carrier billing systems are notoriously byzantine.

Suffice it to say, no one can really deploy an M2M network without working with some partner or carrier go-between.

Embedded Programming

Another major problem is getting an M2M endpoint to capture useful data. Many companies would like to use M2M systems, but that is a problem in itself. All mobile phones do largely identical functions – phone calls, messaging, web connections, etc. This provides economies of scale for the handset industry. However, those feature sets are overkill for an M2M network, as each M2M endpoint needs to do just a small set of functions. The trouble is features vary so widely. Coca-Cola would want to connect to the “out of stock” sensor, and maybe some temperature data. Shell Oil wants to talk to pressure sensors, and sometimes those sensors send routine data while other times they send urgent, critical data.

While M2M devices can be very simple, the wide range of uses means that there is very little overlap and each endpoint has had to be custom built for a handful of customers. No economies of scale here.

The real problem is that M2M endpoints need to have some basic functions programmed into them, but programming devices like this is very hard. This area is known as ‘embedded programming’ as the devices’ functions are deeply embedded in the hardware. A computer can do anything you program it to, a calculator can only do math. Since embedded programming tends to take place on devices with very little computing power, the work involves use of some very arcane programming languages and considerable interaction with the hardware makers. This can become incredibly expensive. The ‘smart meter’ makers have collectively invested hundreds of millions of dollars in this work.

There is no common operating system (OS) for embedded programming, so no common set of tools or languages. In the past we have noted that some M2M companies have taken to embedding Android into their equipment. For instance, we have met several people who are effectively gluing Android smartphones inside flat-panel TVs to create digital signage systems. This is not a perfect solution. Android requires a fair amount of memory and other silicon content to work. For people building M2M systems the bill of materials (BOM) or cost of the M2M hardware is much lower than the BOM for an Android phone. Nonetheless, for small companies, the extra BOM of a few dollars per device is far outweighed by the $100 million it would cost to build an embedded board with some obscure operating system.

The coming of Big Data

Another important problem is that M2M networks tended to create a tsunami of data. If you are collecting data from a few million smart meters, until recently there has been no easy way to make use of that data. We have seen firsthand examples of this in warehouse and logistics companies, with millions of items entering and exiting their facilities on a regular basis.

Fortunately, developments elsewhere mean that a solution is at hand, or at least coming very soon. “Big Data” is a theme we will write a lot more about in the future. The ten-second version is that capturing and analyzing huge amounts of data is becoming easier and much, much cheaper as the result of developments in the Internet world (i.e. Google, Facebook etc., and the tools they have open-sourced). We see this problem as being close to solved, as it is now relatively easy for companies to install basic big data and analytics system.

Retrofit

The last problem is probably the trickiest. Installing M2M endpoints will remain the bottleneck for some time. How does a company like Pepsi go out and weld M2M endpoints into their millions of vending machines. They have many incentives to do so, but there is a real cost measured in unionized labor hours. Our sense is that once the rest of the cost of M2M systems reach some lower point, this obstacle will gradually fade away. Increasingly, machines are being built with Ethernet ports and other similar connection ports. As these become more common, the problem gradually gets smaller. Nonetheless, the M2M revolution will take some.