It’s not every day that a major infrastructure build-out happens.
Imagine that you wanted to switch from your current cable provider, but you wanted to stay with cable technology. The only way you could do that (other than finding some reseller that leverages the cable you’re trying to escape) would be for a competing company to come dig up your town and install a whole new parallel network. Yeah, not likely to happen. (Which is why the incumbent cable companies can act like the monopolies they are.)
Similarly with cell networks, although slightly less so. Here in the US, we started with two providers per geography. Obviously, we have grown beyond that by now, and yet, for the most part, US coverage is dominated by two companies. Others, like Metro PCS, have cherry-picked markets and users, limiting their build-out. But the prospect of a completely new cell provider installing a completely new network to compete with the entrenched big guys seems exceedingly unlikely.
Which means that, when internet of things (IoT) nodes need to communicate over longer distances than WiFi or Bluetooth or Zigbee will permit, then cellular is the next obvious choice. We saw how, unlike for the consumer IoT, cellular is common for industrial use, with companies having access to rate and program APIs that let them change their plan on-the-fly. No two-year contracts here!
But some folks over in France have noted with consternation that cellular technology is not at all well suited to IoT applications. Our phones, originally designed for prosaic human-to-human conversations, are increasingly conveying lots of data, and they’re expected to handle yet more as people do and watch ever more on their phones – especially video.
That volume of data is diametrically opposed to how typical IoT nodes work. Things (of the IoT sort) send minimal data, infrequently. For applications sending a periodic data report, these might be spaced many seconds or even minutes apart. For nodes that don’t send regular data, but rather serve as alerts, they might maintain a heartbeat just so that the Cloud knows that they’re still alive and that no news is indeed good news, but those check-ins are still likely to be infrequent.
OK, so what? If you’ve got an all-you-can-eat monthly pass to the gym and you go only once a week for 15 minutes each visit, it might feel inefficient, but who cares? Where’s the harm? Well, as you might imagine, it’s a power thing. Efficiency too, but that really boils down to power when all is said and done.
One way of looking at the efficiency is to look at the protocols being used for communication to determine how much overhead there is. After all, we usually expect that, when sending a data packet, there’s going to be a hunk of stuff on the front and back that wrap the packet, but that the bulk of the message will be the payload.
That may be the case for an actual packet carrying useful data, but, with the mobile system, the protocol does way more than that. There’s lots of keeping-in-touch so that cells know who’s in their territory and how long they’ve been talking and whether they’re about to move out of range for a handoff to the next cell. That makes for a lot of chatter with no actual user data changing hands. By one estimate, the data-to-protocol ratio for standard cellular systems is somewhere between 0.1% and 1%. Said another way, 99-99.9% of the traffic on cell networks is protocol, not actual data.
Impose that on some poor unsuspecting IoT node, and it seems rather wasteful. To be sure, a reality check will remind us that, in fact, IoT nodes are indeed successfully using the standard cell network today, so it’s not like it’s impossible. The question is whether there’s a better way.
Those guys in France happen to think so: they’ve started a company called SIGFOX (from whom that data-to-protocol ratio came). They believe in this so much that they’re building an entirely new network that uses a new IoT-oriented protocol. Yes, someone is building a completely new cellular system alongside all of the existing ones. And the system is dedicated to the IoT; no phone calls sneaking in for a bit of extra revenue.
They established a specific set of requirements, which I might as well simply quote from their whitepaper:
- “Low cost and thus allowing for any sort of object to be connected in high volumes
- “Low energy consumption to increase battery life expectancy, lower maintenance (TCO), minimize climate impact
- “Ease of use, both in regards to integration in objects but also in regards to object management and integration with IT systems
- “Long range, to avoid having to deploy complex local infrastructures and to reach all objects
- “Operated, to facilitate service level monitoring and object management
- “Frequency-independent, for world-wide coverage and adaptability
- “Embedded subscriber identification, to avoid additional cost and management of SIM cards
- “Penetration should be deep and allowing for underground or otherwise stringent structural environment connectivity”
Regarding the frequency, they’re largely leveraging industrial-scientific-medical (ISM) bands at this point. Use of these frequencies doesn’t require a license, and so this removes some of the overhead of getting this whole thing going. No bidding against someone else and hoping you’ll get some spectrum. But their system can also be adapted to whitespace or to licensed bands.
That said, their point is that the specific band isn’t written into the protocol; in any particular location, you can use whatever frequency band makes sense.
They use ultra-narrowband (UNB) radio, with frequency hopping and anti-replay to help security. Their protocol is very simple: each message has a payload of 12 bytes, and Things are limited to less than 140 messages per day. The wireless throughput is 100 bits/sec. There is no payload format, which they consider to be a security feature: each subscriber can format and encode data as they see fit, which means that, in theory, an intercepted message can’t be interpreted unless you know that particular subscriber’s system.
As a result, they say that their data-to-protocol ratio is 20-50%. That’s still a lot of protocol and non-data communication (a half to 80%), but it’s far better than the 1% or less they quote for cellular. Besides, with a payload as small as 12 bytes, it takes a pretty streamlined encapsulation protocol to keep the efficiency even at 50%.
Based on this, an IoT installation needs no network infrastructure: the modem is built into the Thing itself and talks directly to the SIGFOX cell antennas. Reliability is enhanced by making each Thing hearable by more than one antenna. The backbone has built-in redundancy and active monitoring by the service providers that deploy the SIGFOX technology (SIGFOX doesn’t act as the actual service operator).
Of course, installing a new network like this involves lots of new listening posts – presumably one of the major costs of such a project. They say that a message can travel 1000 km given line of sight, but typical tower separation is 30-50 km in rural areas; 3-10 km in urban locales. Each base station can handle roughly a million Things.
The APIs for Things to access the Cloud are RESTful (GET and POST with JSON payloads). A Thing starts out by registering HTTPS addresses for its apps; messages are forwarded to these locations through their respective apps.
Given all this change, how does the power pencil out? They claim that standard cellular systems use 10,000 times more power than they do; cellular base stations themselves use 200-600 times more power than a SIGFOX base station. They have done an example involving a billion Things, each sending a message ten times per day. Total energy for a standard cellular system to process this: 170-440 MWh. Total energy for SIGFOX: 120 kWh. That’s roughly one 1/1000th the energy.
They also claim to be much more cost effective. Say what you will about how cell phones have transformed telephony, no one has ever accused them of being too cheap. While SIGFOX doesn’t publish numbers, they describe their costs as “radically more attractive.” The annual fee includes connectivity, the APIs, web-based administration, and support.
So, the last big question, of course, is, where are these guys currently deployed? Their current focus remains Europe. They started with “early adopter” cities: Barcelona, Warsaw, Munich, and Milan. They’re still working on Dublin, Prague, Antwerp Harbor, Copenhagen, Stockholm, all of Portugal, and Tunis (presumably the first non-European installation). Also covered by now are the Netherlands, France, the UK, and Spain; Russia is also shown as covered, although not the entire country.
In fact, with all of these, it’s hard to tell exactly how coverage is distributed throughout a location; presumably you’d need to contact the local service network operator for more detail on a specific geography. (Obviously, covering the entirety of Russia is a rather daunting task… pity the poor sensor node that gets banished to Siberia…)
They also have their sights on the following countries as “the next wave”: Germany, Italy, Belgium, Switzerland, Austria, Denmark, Sweden, Poland, the Czech Republic, Ireland, Norway, Finland, Ukraine, and Slovakia. Don’t see your country in there? They’ve got a link for that… (Assuming you’re a service operator interested in running the network in your proposed country…)
As to further expansion outside Europe, there’s not much in the way of specific information available, but, according to their Thomas Nicholls, they will be starting a San Francisco deployment this year, with further expansion through the US to follow, region by region. And they’ll be announcing a mystery Asian country either late this year or early next year.
It seems like an entirely new long-distance wireless system like this would be a pretty big deal, so I was surprised to see how far they’ve come with not much in the way of news this side of the Atlantic. Such a build-out is quite a commitment, so it will be interesting to see how quickly they get traction.
It will also be interesting to see if consumer IoT folks decide to jump onto this bandwagon. That would give WiFi, BlueTooth, and Zigbee something of a run for their money… Yeah, it may not be a competitor to the cable company, and it won’t be a competitor for your cellular phone, but it could be a competitor to all kinds of wireless. That could turn a lot of things upside down.
13 thoughts on “A New IoT Cellular Network”
What do you think of SIGFOX’s new cellular-for-IoT concept?