Sep 18, 2014

M2M in Orbit

posted by Bryon Moyer

This is for those of us that maybe haven’t been paying attention.

The most important concept that turns Things into an Internet of Things is communication. And there are lots of ways to communicate, the favorites of which are wireless. We’ve looked at short-range wireless like WiFi, Bluetooth, and Zigbee. And we’ve looked at cellular.

That should pretty much cover it, right?

Actually… no. First, there’s actually a new cellular flavor coming, but that’s a story for another day. But also, don’t forget satellites. And, in particular, Iridium.

“What??”, you say. “But Iridium closed down, right?” Well, yes and no. The original company went into bankruptcy, and then later, another group purchased the assets for a pittance ($25 million for infrastructure that cost on the order of $6 billion to build out, according to Wikipedia). And it’s been rebranding and operating the network. The satellites were never “de-orbited,” and they’ve continued to function throughout. They’re even planning a new, upgraded network (again, according to Wikipedia).

And now, even they can’t escape the rush by Things to connect everywhere. Or perhaps they want to be part of the big Thing party. Regardless, Taoglas has just announced a module for connecting Things to Iridium.

Module_256.jpg

 

Image courtesy Taoglas

This is, of course, for industries that have far-flung Things to connect – listed by Taoglas as oil & gas, mining, maritime, construction and emergency services. All of which may be found far from a cellular connection.

The module contains the transceiver and the antenna, pre-certified, eliminating losses along the coax that typically connects the transceiver to the antenna. Its industrial-grade housing is waterproof. It’s intended to function in the presence of what are apparently rather noisy electrical conditions on those big mining dump trucks, each tire of which seems wider than a freeway lane. Even the mounting nut and bolt are intended to resist shearing off the equipment on those really badass assignments.

You can find out more about this in their announcement. Oh, and by the way, on the same day, they also announced what they say is the first embedded 4x4 MIMO WiFi antenna, which you can read about here.

Tags :    0 comments  
Sep 16, 2014

ProbMe Simplifies Thing WiFi Connection

posted by Bryon Moyer

Sometime back, we took a look at Econais’s WiFi modules. We mentioned their ProbMe capability, which simplifies connecting these devices to the WiFi network.

This function has apparently gotten some traction, and they’ve made some improvements that they announced in early August. So I wanted to dig in a bit more to understand specifically how this thing works – and get clarification on what seemed (and possibly still seem) like possible complications.

First, why do this at all? This is intended for WiFi modules that will attach to all manner of Things. Most of these Things will not have displays or keyboards, so they are harder to connect to the network than your average phone or computer. How to enter the password, for example?

There is the WPS button; would that work? This is the setup mode newer routers have where, instead of choosing an SSID and entering a passphrase, the Thing listens, and you go push a button on the router; the router and the Thing do a handshake and connect up. But this assumes you have access to the router. It also assumes you have easy access to the Thing – if the Thing is a light in a warehouse with a 20-ft-high ceiling, that’s not so easy. There are also apparent security holes in this scheme (per Econais).

That’s why Econais did this ProbMe thing.  I’ll describe first how it works from a user’s standpoint, then what’s happening inside, and then address some questions.

The way ProbMe works is that, when you first power up an unconnected Thing, it enters a “listening” mode, awaiting connection instructions. The user finds a passphrase in the Thing packaging somewhere and then opens an app on their phone or computer. That app will ask for the passphrase, and then the configuration takes place automatically.

This passphrase isn’t really a security thing; after all, if it’s readily available in the documentation, then it’s not really a secret. This is rather a way to identify which Thing is being configured. And it’s expected that manufacturers may use the same passphrase for many Things (either copies of the same Thing or even groups of different Things that work together, like the components in a home entertainment system).

Because of this, you can configure multiple Things in one fell swoop. If you’re configuring all the new lights in the warehouse, for instance, you turn them all on, do the configuration, and it can work on all of them at the same time. Note, however, that this isn’t a specific thing about ProbMe – the Thing manufacturer has control over this based on how they assign the passphrases.

So what’s happening under the hood to make this happen? The app is using WiFi’s discovery mode to broadcast to all Things. In the configuration field, it has a long string containing the Thing passphrase, the SSID, and the network password; the ProbMe software in the WiFi module of the Thing parses those items, recognizes its own ProbMe passphrase at the start of the string, and then uses the information to connect to the network on its own (or ignores it if it was some other Thing’s passphrase).

probme_screenshot_200.jpg

Image courtesy Econais

How does the app know the network password? If the phone or computer has ever connected to that network before and saved the configuration, then it has that stored away. Which suggests that, if you use, say, your personal phone in the warehouse, and you’ve never connected to the warehouse network with that phone, it seems like it wouldn’t work. You’d need to connect your phone to the network first so that it would know the password.

Some obvious questions arise from this scenario regarding security. And it’s not just a “bad guy” thing; it’s also a consideration of timing.

  1. Once you power on your Things, what’s to stop someone else from configuring them before you get to it? After all, if they bought one of the same things – say, a coffeepot – then they’d know the passphrase (since the manufacturer would probably make them all have the same passphrase rather than going through the logistics hassle of personalizing each coffeepot).

    This is theoretically possible, but it’s expected that the Thing manufacturer would build in a window of time within which configuration had to happen. If it didn’t, then you’d need to power down and back up again to configure it. The chances of someone malevolent just waiting while you power on your new coffeepot is considered remote. But it is something to consider.
  2. Once you’ve configured your Thing onto your network, what’s to stop someone else from reconfiguring it?

    Once configured, the Thing is no longer able to be reconfigured without some manual intervention, like pressing a physical “Reset” button. It’s nothing that can be done wirelessly.
  3. Let’s say a new office building is being opened, and it’s move-in day. It’s modern, with lights having WiFi connections. You want to connect your lights up to your network (and not the network in the neighboring office). Folks arrive at 8AM that first day and turn on the lights. From that time, there is a window within which the lights need to be connected (or else you need to power down and up again). Let’s say it’s a 10-minute window. Let’s say the lights in the two offices get turned on within 5 minutes of each other. There is now a 5-minute overlap in the configuration windows. All the lights have the same passphrase; if one of the offices enters a passphrase within that 5-minute overlap, then all of the lights in both offices will be configured at the same time. And once that happens, you can’t reconfigure without physically resetting each light.

    The answer here isn’t one of technology; this scenario could happen. But, from a practical standpoint, they believe that IT folks for the building itself would handle this, not the tenants in the offices. Since one IT person would be doing it, he or she would be in control of which lights are configured at which times, eliminating any race conditions.
  4. What about the same scenario, only with coffeepots? Unlikely the IT guy is going to configure that.

    This is also plausible, although it’s much less likely that two people in adjacent offices would just happen to purchase the same coffeepot and power them up within a few minutes of each other. It’s also easier to reset a coffeepot than a light (although there’s no guarantee that there might not be Things where this scenario is more feasible and where the Things are less accessible). It remains a consideration.

You can read more about ProbMe in Econais’s announcement.

Tags :    0 comments  
Sep 11, 2014

Proximal Networks

posted by Bryon Moyer

I was keyed into the concept of the “proximal network” by the AllJoyn network, conceived by Qualcomm and managed by the AllSeen Alliance. I started poking around to learn more about proximal networks and to see which other ones might exist.

What I found was that there are two different senses of proximal network, although they share a conceptual basis.

Once concept is what you might call a mesh network for cellular. That concept notes that, if you make a cell call or send a text to a person 20 feet away from you (hey, it could happen…), then that call might travel a mile to a tower and then a mile ±20 ft back. This works up until the point where the tower gets overloaded.

What if a phone-to-phone network could be set up where the call simply went the 20 feet? Calls or data could hop from phone to phone to their destination, bypassing the towers.

There are some obvious issues to be worked for this to happen, not the least of which is the fact that the cell providers lose some control and visibility – unless, perhaps, the phones themselves radio back to HQ to report every call that passed through. My sense when reading up on this was that this might be the biggest barrier to deployment.

Traffic would also have to be managed somehow to figure out which phones would carry a given call. Would it be limited to phones that aren’t in use? Or would streams be multiplexed so that, even if you’re on a call, another call could silently pass through? And would there be enough processing power?

There’s also the security issue: a phone owner should have access only to his or her own call/data stream. Any other streams passing through the phone would have to be inaccessible to the phone owner. And… I guess there would need to be a hand-off mechanism in case someone shuts down their phone or goes out of range while someone else’s stream is moving through it.

Such a network, however, has nothing to do with AllJoyn. AllJoyn is a home network – think Internet of Things (IoT) – where Things can discover and communicate with other Things in their proximity. In particular, it’s transport-agnostic, and can bind together Things using different transport protocols as long as there is one Thing in the network that supports both protocols, and can therefore act as the bridge. At present, it’s been implemented over WiFi, WiFi-Direct, Ethernet, and Powerline. Others, like Bluetooth LE, are open for implementation.

The focus with AllJoyn is on interoperability – being able to take diverse Things with diverse transports and get them all talking to each other in a manner that’s accessible to your average person.

Note that AllJoyn typically can’t penetrate a firewall simply because of the network address translation (NAT) issue. Inside the home, you’re using private IP addresses; at the gateway, it all gets translated to your single public IP address. The private addresses for Things aren’t public, and they get lost when they cross the firewall.

I started to speculate on ways that such a protocol could bridge across firewalls, although it would only apply to Things that ran over IP. But I decided that this was speculation of a not-particularly-useful kind. As AllJoyn is defined, it doesn’t do this, and communication can’t pass through the firewall. Which, critically, means that someone shouldn’t be able to penetrate your firewall and fish around for your Things.

The common thread between these two different concepts is that networks should be defined by what’s in the neighborhood, not by what protocol is running. In the cellular mesh idea, you might use some other transport mechanism to get to a neighboring phone in the same manner that Things running over IP and Bluetooth could interact over AllJoyn.

You can find out more about AllJoyn here; you can’t find out more about any real-world cell-style proximal network, since, as far as I could tell, there isn’t one: it’s only an idea at present.

Tags :    0 comments  
Get this feed  

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register