MXProtocol’s anti-collision coordinator — what it is, and why the IoT needs it

There can be little question about it- the IoT is already beginning to feel crowded and we’ve only just gotten started in exploring its potential. Imagine a commercially operated IoT network in the very near future, trying to co-ordinate most or all of the IoT capable devices in an area of hundreds of square miles. Remember that each signal is a tiny, ultra-low power string of ones and zeroes oozing across this network at a bitrate that would make a dial-up modem feel superior.

Oh, I forgot to add — the devices attempting to access this network are all made by different manufacturers, and running different firmware. Better still, the network is segmented across a few different clients, and they don’t like to share. …at least, not without being compensated for the resources used.

Part 1 — Anti-collision has nothing to do with self-driving cars. In fact, you’re probably using it right now.

The problem you’re imagining is called collision avoidance. I won’t go deep into the tech — if you need to start with what half-duplex communications are, there are good resources all over the net. For the more ‘advanced’ details, see part 2 below.

Networks have the same trouble talking on a single frequency that old fashioned CB radios do. You can talk or you can listen, and if 2 people try to talk at the same time, all anyone hears is garbage. That ‘garbage’ is called a collision.

There are quite a few discrete frequencies available, to be sure. But not an infinite number, and most IoT devices are fairly limited as to what frequencies they can use to broadcast or receive. After all, they have to be tiny and ultra-efficient. They don’t have the luxury of broad-spectrum communications.

Therefore, this isn’t a 4 lane motorway, with convenient on and off-ramps. It’s a train track. 2 trains can use the same track. They can even do so at the same time if they are far enough apart. But if they try to use the same frequency (track) in the same place (say, a few hundred feet) at the same time (big, long seconds at these low bit rates) you lose trains (packets of data) when they collide.

If the words ‘nightmare’ or ‘impossible’ came immediately to mind you’re on the right track, but just a little bit behind the times. There are several workable strategies being fielded today or in the very near future. However, one of them in particular has a bespoke anti-collision coordinator which is miles ahead of the competition. Literally — they’re shooting for 20mile radius networks.

Why are ‘collisions’ such a bad thing?

Well, in a wired network, they aren’t. They’re annoying, inefficient, and slow things down generally, but they can be detected and the packets can just be re-sent. The whole process takes a few microseconds, and the users probably never notice.

In a wireless network, it is more difficult. Say a smart phone and a laptop are competing for the same network resource at the same split-second. Those collided packets come through as indecipherable garbage. The network coordinator has no idea where they came from or where they were supposed to go. It definitely has no clue what they contained. It can’t even tell how many discrete packets were in the pileup. That data is just lost, and unless the receiver has some way to detect that they didn’t get everything they expected AND the transmitter kept a back-up of all of the packets it sent, it can’t even be tracked down and re-sent.

In a LPWAN, things are even worse. LPWAN bitrates are sloooow. A packet that would scoot across a wireless N network in so little time that non-computer people don’t have words for it takes up an entire frequency across an entire volume of space for an amount of time a mere human can notice. On a computer scale, these trains are 100 cars long and never get above 20mph. There are a lot of trains waiting to use that track, and if that rail network (LPWAN) isn’t rigidly and efficiently coordinated, no one is getting to work today.

OK, no more train analogies. I promise.

What MXProtocol is making possible for LPWANs

When MXC set out to build the gold standard for LPWAN collision avoidance, they set themselves 4 key goals:

1. Minimisation of packet collision across uplinks from multiple networks in a very wide area
2. The ability to allocate resources for downlinking to devices on those networks on the fly
3. The ability for Network A to use and pay for access to Network B as needed (essentially, network roaming)
4. The ability to keep all money transfers ‘in house’, settled by MXC alone.

They go into quite a bit of detail about that in a white paper. Give it a read.

MXC’s coordinator therefore needs to do 2 things, and do them very well indeed. It needs to handle payments, which is perhaps the subject of another article, and it has to juggle thousands of IoT devices clamouring for uplink and downlink time in an orderly, reliable manner.

To dive once again into the technology metaphors of the past, the coordinator acts as the entire network’s old-time phone operator, connecting the necessary devices and clients across whatever network resources are available, preventing devices from stepping on each other’s signals and generally keeping the whole weird wiggly mess of a real world IoT ecosystem functioning smoothly.

Part 2 — How does it actually work?

MXProtocol’s anti-collision coordinator is specialised for the IoT environment. That means it works well within both the tight constraints of a LPWAN environment and the economic pressures of a system that makes money from many, any very tiny pieces of data.

What are Low Power Wide Area Networks?

LPWANs (sometimes LPWAs or LPNs to their close friends) do ‘just what it says on the tin’. They connect wireless devices over a very wide area — often several kilometres wide — without drawing the kind of power we usually associate with kilometre-range radio communications. Both the range and the power-stinginess are vital to IoT applications, as by definition the networked sensors, processors and other devices in a commercially viable IoT network cannot be big, power-thirsty modules. They don’t have to deliver data quickly, but they have to do it constantly and with just a few wisps of power. In fact, many are required to be battery operated, and some are constrained to work for weeks or months without a re-charge.

The next generation of large scale LPWANS may have to connect thousands or even hundreds of thousands of tiny, low power transceivers scattered across as much as 1200 square miles of densely populated city. Needless to say, there are some technological hurdles to jump.

MXProtocol’s anti-collision coordinator at work

So, in practical terms, what actually happens when the coordinator detects a potential collision? How does it prevent packet loss, and what are the repercussions?

A typical scenario might look like this: Device A wants a high priority downlink from User A on Channel 1. Let’s say it is a smart home’s door lock or a command to turn on a light — something the user will not be patient about, but something that has no access to Channel 2+. However, Gateway 1 is already using Channel 1 for Device B. The coordinator keeps track of all of this, and prevents the collision before it happens.

The anti-collision coordinator makes sure that that downlink happens over Gateway 2, which is just a few hundred meters away. Since the coordinator handles both gateways, it credits Gateway 2’s owners for Gateway 1’s spill-over traffic, and charges the owners of Gateway 1. It also pauses Gateway 2’s Channel 1 activity so that there isn’t a cascade of new potential collisions.

But what about packets that do collide?

Well, they are lost, but the co-ordinator can learn from its mistakes.

First, lost packets can be tracked. Both networks that lost packets are able, at least in the MXProtocol model, to report those lost packets. They know where they should have come from, what the device’s sending intervals were, and even the devices’ physical distance from each other. The coordinator can use this to determine how the collision happened, and change one or both devices’ sending intervals or their data rates to make those collisions substantially less likely.

In this scenario, that might mean that the data stream from Device C is delayed a few seconds or minutes in favour of Device D. That doesn’t represent a huge burden, but if any degree of burden can be imposed, someone will feel ill-used sooner or later. So the financial aspects of the system step up to make things right.

Device C’s operator, owner, or whoever stands to benefit from its data is compensated automatically at a pre-negotiated rate from Device D’s account. If Device D’s owner/operator wouldn’t have been willing to make that payment at that amount, their signal might have been delayed instead, and the compensation would have flowed the other way.

A note about the coordinator’s currency transactions

All of these transactions take place in a purpose-built cryptocurrency, the MXC. I’ve written elsewhere about how this cryptocurrency is closely linked to IoT data, and how its uses blockchain technology to permanently tag a segment of data’s creator(s), owner(s) and history. This allows for those who use the data to compensate its creators all the way down the line. Any attempt to alter the blockchain destroys the data.

But this is straying beyond the work of the actual coordinator. More details are available here had here.

And the system is ready to be integrated into 3rd party LoraWAN servers.

MXProtocol’s anti-collision coordinator already exists as a protocol plug-in that is fully compatible with existing LoraWAN servers. The plug-in essentially controls the MAC layer of the network’s uplinks and downlinks.

The coordinator can be implemented either as a full node or as a light node. The full node integrates into the network’s protocol layer, and prioritises uplinks and downlinks based on payment logic and other practical concerns. This is the set-up I used for the examples above. The light node connects to another full node to provide a wallet for these transactions.

I understand that a detailed white paper for the coordinator’s implementation in Lora servers is forthcoming.

Will all this make currently free LPWANs more expensive?

Not in absolute terms. Think of this as a kind of premium service. You could run a free, uncoordinated LPWAN, but now you have the option of using MXC’s much more efficient system. Rather than counting the cost of lost packets and inefficient operation, you can pay pennies to have a system which actually manages itself, and does so in a fair, equitable and transparent way. If it didn’t make its users money, no one would use it.

Is all this really necessary?

TLDR: Yes.

Right now, these collisions and potential collisions are fairly rare. Mainly because right now these networks are small, and very sparsely populated. The number of IoT devices using LPWANs is literally exploding, and the financial pressure to make use of that flood of data makes physically larger and larger LPWANs a practical necessity.

Active, predictive, and financially integrated coordinators are one of the best ways to make these networks actually work at the scale the very near future demands.