At any given moment, it’s hard to tell whether the Internet of Things (IoT) is a technology or a mish-mash of technologies. It tends to feels like more of the latter, with its massive pile of protocols and approaches.

Well, this week we look at yet another angle – one I hadn’t seen to date. To set this up, there are a couple of notions we should focus on. One is the idea of mobility. The company we’re going to discuss points out that fixed IoT edge nodes often connect directly to the cloud. A phone might be in the picture, but the phone very often contacts the cloud, which contacts the edge node. Even in an app where the phone is more or less a remote control for a sensor, it’s going through the cloud to get to it. What they refer to as a mobile edge note, by contrast, communicates directly with the phone, since at any point in time, it may or may not have access to a cloud connection.

The other idea deals with message initiation. Very often we think of picking up the phone, opening up an app, and then somehow interacting with the IoT. We, via our phone, are the instigators, and we initiate the interaction by turning on the app. But there are situations where perhaps the edge node should be the initiator. But… if your phone is in your pocket and the app isn’t open, then there’s no easy way for the node to get your attention. It has to send an email or text or something, and you have to notice that it arrives.

So today let’s combine those notions: mobility and edge-first interaction. And let’s set up an exemplary use case for this: a pallet of temperature-sensitive goods. Heck, let’s say boxes of ice cream bars. They’re in transit from factory to store (and, ultimately, to mouth), and they’re using a refrigerated conveyance to get there (the kind of reefer that the feds are OK with).

So these things get loaded onto one truck, moved to a warehouse (chilled), where they get transferred to another truck. That second truck hauls them to another warehouse somewhere else, in a different town. Except it turns out that there’s a problem: the refrigeration isn’t working very well in that second truck, and it’s super hot out. It stays cool and comfortable in the back, but not cold: it gets above a magic temperature of, oh, say, 33 degrees. (F.)

And so some meltage starts – a little. No big puddles of cream on the floor, just loss of shape and some oozage inside the box. Not a good look. But, since you can’t see it from the outside, who’s the wiser? Certainly not the driver, who delivers his load, which then gets transferred to yet another truck – this one with refrigeration intact, and the goods freeze up good and solid again – in whatever shape they were left in.

Now that pallet of ice cream bars gets delivered to stores, stocked on shelves, and purchased by customers who are also none the wiser – until they open the bars and see the carnage. Now… a little meltage might be ugly, but perhaps not dangerous. And yet, as a customer, how do you know that little somethings weren’t given a chance to grow on the bar during the few hours of summer that it experienced? If it were meat rather than ice cream, the risks would be much higher.

In other words, a cautious parent will throw them away or return them. Neither is good for the company – cost of return, possible recall, loss of brand goodwill. (Of course, some parents will scoff, with a firm, “It’s just fine! Eatcher dang ice cream and stop moaning!”)

So…  unless each truck driver monitors the temperature carefully, how is anyone to know that, deep within innocent-looking boxes, lurks ice cream mayhem? This is where temperature tags can help: a temperature sensor that tracks the ambient temp, and if it ever rises above some preset value, then it flags an alarm.

Now, when the pallet arrives somewhere, you can find out that the goods haven’t been kept in the desired condition, and that there may be problems. How to implement this, however?

First of all, this tag is an example of a mobile edge node. Second, it’s going to want to tap you on the shoulder and say, “Hey, just to let you know…” In other words, it’s going to want to initiate the conversation. It’s also going to need to preserve its battery for as long as possible, so low power will be the name of the game.

We’ve seen a number of ways for a node to communicate with the world – WiFi, ZigBee, Bluetooth, cellular, LPWANs, etc. – but if the main goal is to get the attention of a phone, then WiFi and Bluetooth are the obvious candidates. If it’s only a little bit of data being sent – say, the max temp that the pallet experienced – then WiFi is probably battery overkill; Bluetooth Low Energy might be a better fit.

But does that mean that we need to pair with every pallet to check it? And would we have to keep the app open all the time, just in case? This is where a company called Enmo has seen an opportunity – but one that requires some work on their part to realize.

See, there is a way to alert your phone without an app being open: using beacon technology. The good thing about this is that a phone can respond to beacons without having any apps open. So this would allow the edge node to initiate the conversation.

But there’s a problem: beacon technology leverages the advertising mode of Bluetooth, and there are two limitations to that mode. First, it carries no user payload; it simply says, “Yo, I’m here!” Yeah, if you look at the Bluetooth spec, it shows a payload, but the contents of that payload are specified by different advertising modes, and so, as far as I can tell (and according to Enmo), you can’t put a random payload of application-defined length in there. Second, there’s no way to respond to a beacon; it’s a forward channel only. You normally need to pair and establish a connection before sending data back.

And this, then, is the work that Enmo has been doing. They’ve built over the advertising mode, developing a way to deliver a small packet and to return a packet. For our particular ice cream example, once temp has been exceeded, the tag starts broadcasting an alert. A nearby phone equipped with the appropriate technology picks up the SOS, even if tucked inside a pocket with the screen blanked. Once the message has been heard, the back-channel can be used for acknowledgment, and the tag can stop transmitting because it knows it’s been heard.

This is, of course, just one possible use of this so-called IoT-over-Beacon technology. Without learning too much in the way of specifics, the sense I get is that there are a surprising number of folks in play here with surprising and unusual applications for technology like this. Needless to say, Enmo is being relatively quiet about them so as not to give things away.

Of course, there’s one big question here: security. And this one is being worked. Enmo is partnering with Ionu for packet encryption. Sounds simple enough, but you’ve got the whole key management thing to worry about. Should they use PKI? What assumptions can one make about the capabilities of the edge node? Can it handle sophisticated key management (such as is possible with surprisingly inexpensive silicon designed for this purpose)? What about authentication in general – who’s allowed to listen to the alert?

It’s a work in progress, and I’ve gotten a mixed sense of when it will be in place. But presumably it will happen.

I also have a general question regarding interference. In the example we looked at, we have a pallet with lots of boxes on it. All the boxes experience the same environment, and so a single tag can speak for them all. But what if these pallets were being mixed and matched in the transit warehouses? Now you can’t assume that all boxes on a pallet have seen the same temps, so you really need a tag on each box so that you can separate out the good stuff from the spoiled stuff.

So now you get a pallet showing up, and let’s say that half of the boxes heated up along the way. You have many hundreds – perhaps over a thousand – boxes on this pallet, half of which are screaming for attention. How do you deal with that?

At the simplest level, the phone can select one, acknowledge, and move to the next, shutting them down one at a time as they’re located and dispositioned. But there’s a second problem: all these tags shouting at the same time are going to interfere like crazy. In order to shut each one down, the phone has to be able to identify a clear message, meaning there can be no interference from other tags.

The phone also has to be able to send a clear acknowledgment in order to shut down the tag being handled. That’s fine if the back-channel uses a different frequency, since there’s only one phone. I don’t know for sure, but my suspicion is that this isn’t the case – that it has to leverage the usual set of Bluetooth frequencies.

You might note that Bluetooth actually has three channels for advertising. Why not, say, dedicate two for the forward channel and one for the back channel? Then you could cut the forward interference in half and get no interference on the acknowledgment.

Except that, that’s not how Bluetooth advertising works. Yeah, there are three channels, but an advertising packet gets sent to all three, over and over. The purpose of three channels isn’t to build capacity; it’s to increase the chances of a message getting out in the event that the airwaves are crowded. So, unless there’s a way to change that advertising behavior, you can’t allocate channels; they’ll all be equally jammed.

This ultimately gets down to a question of “packet density,” if you will. Which is determined by tag (or, in general, edge-node) density. The packet density will depend on the duty cycle for each advertising burst from each node. If you can make the burst short and then wait a while, other tags get a chance to speak, so, in theory, you should be able to get some number of clear messages out. At some point, of course, you’ll saturate.

But it’s not even that simple. The timing on each tag is independent, so you can’t literally do time-domain multiplexing since there’s no central timing coordination. Advertising can’t do collision avoidance (listen, then back off if necessary); instead, the advertising interval (which is fixed by the designer) gets a random adder so that you can’t get locked into an unwinnable timing battle with some other device that happens to have really similar timing.

But, in our case, that random thing doesn’t really help. You’ve already got these tags shouting away, and, having different clocks on each, their timing will slowly precess around, and you have random opportunities when one tag could transmit in the clear, with no interruptions. Remember that these tags could be broadcasting for days before being heard, so slight clock mismatches will have plenty of time to show their effects.

In other words, there’s already randomness built into the system, based on small clock differences, so the random interval may not have much of an impact. If one tag is in a bitter duel with another one, it can help to break up the fight sooner (rather than waiting until the clocks precess past each other). Note that standard advertising packet timing may not apply, since there’s a payload involved. That’s more data than would ordinarily be sent in an advertising shout-out, so presumably each shout lasts longer than a conventional advertising burst.

There are ways of trying to synchronize BlueTooth nodes, but this isn’t really a synchronization problem. Heck, that might make matters even worse – you want the nodes to fire at different times. The real issue – and savior, frankly – is the differences in drift over time, so synchronization per se won’t really help.

Having gone through my scenario speculation, I did check in with Enmo on how they deal with this interference question; I haven’t yet received a response on that. (If I do and it changes anything, I’ll add an update.)

In the end, there’s a density limit that must be respected. Hopefully, the limit will be high, but it will always be there, and it must be taken into account in the overall application design.

Enmo’s focus is on the cloud platform that allows you to define the interaction with the edge node – the usual business-rules and alert-definition thing. As a SaaS offering, you pay $99/month for up to 5 users. The first 15 days are free. If you get into production, then, at this point, it means a specific discussion with Enmo to negotiate terms.

We should be seeing more from these guys soon, and I’ll follow up with any further details – especially on the security angle.

More info:

Enmo