The Internet of Things (IoT) has a bull’s-eye on its back, and it’s easy to see why: There are no central IoT standards today, and no real oversight over development on smart devices, which now number nearly 5 billion, according to Gartner estimates. Unfortunately, little has changed since last year in this regard.
At issue is the fact that most IoT devices use proprietary technology. They do so because there are no de facto standards to speak of for popular devices, such as smart thermostats. IoT providers still view the market with a gold rush mentality: They figure that the more they can leverage their own technology, the more market share they can obtain and retain.
Moving to a standard will, eventually, become more compelling for these vendors. That's a good thing, because developers (and users) are increasingly demanding standards, which they see as desirable to protect their investment in IoT devices — and their jobs.
For instance, if you purchase an IoT-enabled home thermostat, you want the device to use an open standard that allows third-party applications to communicate and control the thermostat, as well as other home IoT devices. Users also want devices to support an effective security standard so that they won’t wake up one morning to discover that hackers have turned up the heat to 100 degrees—or unlocked the doors.
Blocker: Each vendor has its own agenda
When consumers start demanding IoT standards for the devices they buy, vendors will have to provide them to remain competitive. Device manufacturers will want to control the standard, even though they are working with dozens of other companies, including competitors, so that they can drive the standard in a direction that fits their agenda. Vendors have their own selfish motivations with regard to pushing standards. So buyers who want standards that deliver value need to understand those motivations.
Several IoT standards alliances have been formed, some partisan, some more independent. By 2014, a handful of these were maturing, and today a few have even begun to certify products on a limited basis.
Considering that standards are pretty much driven by companies that have their own agenda, the question is, Do you need standards at all? Also, if standards are created slowly by committee, will they be obsolete shortly after their release?
Users increasingly find themelves in a world of Wi-Fi, IFTTT, SmartThings, and other innovations designed to bring incompatible technologies together. Beyond compatibility with some well-established communications protocols such as Bluetooth, ZigBee, and Z-Wave, many are asking whether IoT standards are already irrelevant.
But a few organizations still care about standards—mainly the ones that continue to develop them. One key thing to understand is that the IoT requires a ton of technology to make it work, from wireless communications to data security to communications between devices. A single standard is unlikely to cover everything, just as a single standard cannot cover the way your laptop works.
IoT communication standards: Take your pick
Network communications is core to the IoT. It's about how these devices talk to each other, as well as to centralized servers. And the standards to which you should pay close attention deal with communications at the most primitive levels.
IEEE 802.11ah
Wi-Fi will remain at the heart of most home networks. But the IoT needs lower-power communications technology for devices that use batteries. Enter IEEE 802.11ah, a version of Wi-Fi with lower power consumption that's due for approval as a standard in 2016. According to the IEEE, however, this standard is still evolving.
The Wi-Fi Alliance has introduced the term "Wi-Fi HaLow" as the designation for products incorporating IEEE 802.11ah technology. This standard operates in frequency bands below 1 GHz, which translates into longer-range, lower-power connectivity to Wi-Fi-certified products.
Bluetooth Smart
Bluetooth is another popular communications protocol for IoT devices. The version of Bluetooth for the IoT is a low-power version called Bluetooth Smart (or Low Energy). It's expected to add a longer range and support for mesh networking capability, where each IoT device acts as a communication node that relays communication from itself and other nodes back to a central control system.
Z-Wave
Z-Wave, another IoT communications standard, is more of a de facto standard than a traditional one approved by a standards body or industry consortium. It's a low-power mesh networking technology licensed by Sigma Designs. Zwave operates at 908.42 MHz in the US (868.42 MHz in Europe), and enables a single mesh network to support up to 232 nodes.
ZigBee
ZigBee, developed by the ZigBee industry alliance, is another mesh network based on the IEEE 802.15.4 standard that's designed to be used in low-power home devices. The technology defined in the ZigBee spec was purpose-built for the IoT, driving communications with less expensive devices.
6LoWPAN
This strangely named standard is an IPv6-only version of IEEE 802.15.4 mesh networking. It grew out of "the Internet Protocol [that] could and should be applied even to the smallest devices." This means that low-power devices with limited processing capabilities should work and play well with IoT systems.
ULE
The ULE (Ultra Low Energy) alliance recently introduced ULE, a low-power version of the Digital Enhanced Cordless Telecommunications (DECT) cordless telephone network technology, which is the current de facto standard for residential and business cordless phone communications.
Thread
Thread is one of the youngest of the standards groups but arguably has the most momentum, thanks to backing from Nest, the popular programmable thermostat that has beome the poster child for the IoT. (It's now owned by Alphabet, Google's parent company). Thread is an ambitious, wireless-centric standard that covers networking, power conservation, security, and product compatibility. Also, every Thread-certified device gets issued an IPv6 address, which could ultimately ease networking issues for IoT devices as the IPv6 protocol gains broader acceptance.
Bigger standards to consider
AllJoyn
The Linux Foundation's AllJoyn protocol, originally designed by Qualcomm, was the standard behind what became the AllSeen Alliance, the first serious IoT standards group to formally launch. AllJoyn is an open-source framework that directs connectivity and service-layer operations for IoT devices in order “to create interoperable products that can discover, connect, and interact directly with other nearby devices, systems, and services regardless of transport layer, device type, platform, operating system, or brand.” Unlike Thread, AllJoyn isn’t a radio protocol, so these two standards could peacefully coexist.
The AllSeen Alliance boasts over 170 members, including Microsoft, Sony, and Lowe’s. The group continues to grow and has been picking up support from blue-chip companies on a regular basis. Recently, AllSeen Alliance’s AllJoyn user group program surpassed 600 members. Keep an eye on this standard going forward.
OIC
Intel founded the Open Interconnect Consortium at the same time as Thread, but uptake and interest haven’t been nearly as high as for the Nest-backed organization. The OIC has largely been seen as a response to the AllSeen juggernaut and a direct attack on Qualcomm.
IIC
As the name implies, the Industrial Internet Consortium (IIC), founded in March 2014, is working on guidelines related to industrial IoT applications. It’s mainly backed by large enterprises, including GE, IBM, Cisco, AT&T, and Intel. These five companies have permanent seats on the IIC Steering Committee.
The IIC has said that it’s not developing standards of its own but is working to “bring together the organizations and technologies necessary to accelerate growth of the Industrial Internet by identifying, assembling, and promoting best practices.” Gartner has questioned the relevance of the consortium, but the IIC did release an Industrial Internet Reference Architecture last summer.
While that's not a standards document, the reference architecture does outline key characteristics of industrial Internet systems, various viewpoints that must be considered before deploying an industrial Internet system, and an analysis of key concerns regarding the industrial Internet, including security, privacy, interoperability, and connectivity.
ITU SG20
Established in June, 2015, the International Telecommunication Union has an emerging standard that is designed to cover the IoT as well as “smart cities and communities (SC&C).” The SG20 standard “is responsible for international standards to enable the coordinated development of IoT technologies, including machine-to-machine communications and ubiquitous sensor networks.”
IEEE P2413
The IEEE project P2413 serves as the umbrella for all of IoT. Again, the goal is to build a reference architecture that “covers the definition of basic architectural building blocks and their ability to be integrated into multi-tiered systems.”
Apple HomeKit
It would be foolish to discount Apple's HomeKit, which the company describes as a “framework for communicating with and controlling connected accessories in a user’s home.” This isn’t a standard, really. It's Apple’s proprietary way of doing things within its own ecosystem. As such, developers and hardware manufacturers can either choose to join the club or stay outside of its walled garden. HomeKit devices are actually shipping, and nothing drives a standard more than real products on the shelves. But Apple controls the HomeKit ecosystem and gets to approve which products can use it.
IoT developer's dilemma: How to choose?
If you’re a developer and need to select an IoT standard upon which to build, which should you follow? That might not be the right question. It all comes down to defining your requirements and then looking for a standard that will enable them, regardless of whether you’re defining a device, a communications mechanism, or a centralized resource.
The larger question is, What problems do these standards solve? There are too many standards today, and many of them are redundant. So how will it all play out? Not all of these standards are going to make it, and no one wants to bet on the wrong horse. As with the VHS-versus-Betamax videocassette standards battle, you risk committing to a standard and that ends up being a loser.
So should you wait?
Not necessarily. The standards shouldn't lead you, but you should examine each and the value it brings for your application. For example, your devices need to communicate, so you might as well pick a standard communications protocol rather than a proprietary one.
But there is an argument here in favor of choosing a de facto standard as well. Some providers' products will become so popular that these companies can define a standard all by themselves. While you might be choosing a "standard" that they create and control, it may very well be the way in which standards evolve in this next phase.
Unfortunately, you can't wait for the final standards to emerge: You need to build IoT systems now. If you wait, you're likely to miss the IoT boat. Think about it this way: You're building apps for devices that are expendable—that is, cheap to replace at a later date, as standards solidify. You could also make the argument that IoT is more about centralized data processing than the devices that just collect data and respond to centralized intelligence and control. In that case, standards won’t matter much.
You might also argue that standards are a distraction from the real problems that people need to solve, and this claim might not be far from the truth. Standards have provided blueprints for how things should be done in IT over the years, but, for the most part, they have ended up on the trash pile without delivering much value.
The problem with IoT standards
The biggest challenge is that there are simply too many competing IoT standards. Ultimately, the creation of IoT standards with redundant purposes offers very limited benefits. That is, until you use them to frame your own requirements for building and deploying IoT systems.
Questions that you need to ask yourself at that time include:
- What value does a given standard bring to my IoT application?
- What are the risks of not using a specific standard?
- What are the risks of leveraging a standard that ultimately fails?
- Can I have input into the standard, and, if so, what’s the process and degree of difficulty for participating?
Don't fall in love with one or two standards this early in the game. Just understand the value each standard brings as you consider it, and look for the best fit for your needs. Depending on your requirements, even going in a proprietary direction may not be a bad idea, for now. Ultimately, most of these competing standards won't survive, and if you wait for final standards to emerge, you'll miss out on market opportunities.
What are you choosing, and why? I look forward to your thoughts and comments.
Image credit: Flickr
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
