Also, I'd note that if the M2M scenarios discussed must involve use of comparatively low frequency TV bands, I'm not sure that very short range or very small devices are a good match.
When dealing with high VHF and low UHF, you are talking about long range propagation potential and about relatively long antenna elements. If you decide to use very compact antennas, then the transmitter power may have to be raised to compensate.
All of which told me that if someone is talking about using the TV bands, they must be considering relatively large areas - at least WiFi type of coverage, and possibly even a lot more than that. Not Bluetooth PAN size areas.
There's nothing unique about the TV frequency bands that either 802.11 or 802.16 could not be adapted to. And there's nothing implied in M2M that is necessarily restricted to low power or to low data rates or to 1000s of devices on the head of a pin. I've been doing M2M all my career, including (but not by any means exclusively) M2M over Internet protocols, and I'm not at all sure that the boundaries you place on this M2M and/or IoT are valid?
As of now, 802.11 and 802.16 use 20 MHz channels, which can be aggregated up to 40 MHz and eventually even 100 MHz. This can theoretically be achieved by aggregating multiple TV 6 MHz channels, or the 20 MHz channel width can be reduced in the adaptation of 802.11 or 802.16.
Modulation schemes for such comm links are pretty much all migrating to COFDM these days, where the symbols can range from QPSK to 256-QAM. So you can dial in whatever spectral efficiency vs robustness you want, in the TV bands or L band or whatever. Even LTE fits that description, including the 20, 40, 100 MHz aggregated RF channels and the COFDM modulation.
Or if you prefer, the TV bands can be used with 3G style spread spectrum, at roughly the same spectral efficiency as you can dial into any of the other schemes.
I'd say, *if* you want to share the same RF frequency channel among lots of devices, and you only need low data rate, 802.11 is a good bet. But that's just one use case, as far as I'm concerned.
Bert, for a start the M2M links discussed use whitespace TV spectrum. Non of the standards you mention do that. Secondly, whilest I'm sure some may work OK, would any be anything approaching optimum? There's more to RF design than just range and frequency. Two requirements that immediately spring to mind for an IoT application that are not necessarily covered by any of the standards you site are ultra low power and very low data rates, for example. Can any of the standards you site be used to efficiently handle 1000's of things all sharing the same RF resource to transmit a few hundred bits per day?
I'm assuming here that you aren't limiting the discussion to RF links only, yes? The reason for long range is, for example, a scheme whereby Samsung can automatically download updates to your HDTV set, for example. This is a typical M2M application that isn't confined to short range. The RF link very well could be, of course, but in that role, the RF link would be no different from, say, your in-home WiFi to reach the broadband modem in your home.
Which is exactly why I don't get the point of this. M2M is no different from any other communication channel, as far as the lower protocol layers go at the very least.
I first of all do not understand the need for long range communication channels for M2M communications. Are machines supposed to talk to their counterparts across the globe?
In my opinion the idea of M2M communications is for the smart machines to be able to communicate with their service centers and owners ( somewhere in their vicinity)
It makes more sense if this standard body is where all the companies come together and agree to interface to each other. If the standard is defined but noone wants to follow, it will never be successful.
Perhaps my real issue with this is the idea that ONE unified standard, all the way up the ISO layers, can cover all M2M needs.
What are we talking about? Turning lights on or off in your home is going to be hugely different from telematics between cars traveling on the freeway, for example. The RF layers might not be necessarily different, but the rest will be.
Does it make sense to try to shoehorn these different jobs into a unified, all-encompassing new standard?
What I think is, people must be making an awful good living at creating standards bodies, because this seems like the ultimate unnecessary new goal.
Just like the idea of creating a new M2M interface "standard" doesn't make sense to me, given that we already have about a kazillion M2M interfaces out there, if the interface becomes RF rather than cabled, I don't see how this changes anything.
There are RF standards for long range, short range, high frequencies, low frequencies, digital analog, cellular, spread spectrum, etc. To me, existing RF standards should be instantly applicable to M2M, because most of them are already used for M2M, and have been for decades.
If you're talking TV bands used at longer range than "personal area network" range, it is not difficult to adapt WiFi or WiMax (to name just two obvious candidates) to those frequencies. I'm really puzzled about what an M2M RF interface would require that either of these two standards can't provide, and they can be used at ranges from home-sized net to metro area net.
Or if a more seamless cellular roaming scheme is needed, then we have 3G and 4G that would be fine too.
Point being, even if an RF link is used for humans to talk or to browse the web, the RF aspects of the link are ALWAYS M2M. Always. Humans aren't there selecting frequencies, selecting FEC code, selecting modulation, or even selecting antenna aim.
Why does anything change, just because the information content on the RF link does not immediately go to a human interface GUI?
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...