The Challenges in Bringing IoT Solutions to Market

The Internet of Things (IoT) has been around for more than 20 years, and a host of wireless technologies have sprung up to support its deployment. In the home, voice assistants have established themselves as the primary user interface to an array of smart devices. Despite these advancements, more than a third of IoT projects never make it past the proof-of-concept phase. Furthermore, the European Commission is concerned that a lack of competition in some application spaces may be hindering market entry for EU businesses. So, what are the real challenges, and what is it like to deploy an IoT solution across Europe?

IoT Tech

If you want to get a feel for the technologies behind the IoT, finding a raft of suitable projects doesn’t take long. Just search for “IoT” and your preferred prototyping platform, and you’ll be overrun with pages of projects, cloud platforms, technology comparisons, and lists of ideas. Elektor is also a great source of information. Since the term IoT was coined more than 20 years ago, our website has collected more than 600 articles on or related to the topic.

However, there is a considerable gap between a prototyped platform that demonstrates the core concept of an IoT solution and deploying one for real. The IoT Insights report from Microsoft interviewed more than 3,000 IoT professionals in 2021. They found that 35% of IoT projects experience failure during the trial or proof-of-concept phase, up 5% on their survey from a year earlier. Most cited as the reason for failure at this stage is the high cost of scaling. Other reasons include too many platforms to test, too many use cases to prove, and a lack of resources. A separate study by Cisco reported that only 26% of companies surveyed thought their IoT initiatives had been successful. Responses to their study showed that, while most IoT projects look good on paper, they proved to be more complex than initially thought. Despite such gloomy feedback on IoT overall, there are sectors where IoT is making huge inroads and delivering growing revenues.

EU Commission Reviews Consumer IoT Sector

EU citizens have welcomed the range of consumer IoT solutions on offer in recent years. So much so, a Smart Home revenue report from Statista predicts that related revenues will double from around €17b in 2020 to around €38.1b in 2025. Concerned that competition in this sector may be being stifled, the European Commission undertook an inquiry as part of their digital strategy . The report, released in January of 2022, garnered input from manufacturers of wearable devices, connected consumer devices used in the smart home, and those providing services over such smart devices. Additionally, the Commission requested input from standard-setting organizations. However, upon reading, many paragraphs of their analysis are given to the voice assistants (VA) that form the user interface to many IoT products and services.

Having analyzed the landscape of the smart home, the report  makes it clear that, in Europe, Google’s Google Assistant, Amazon’s Alexa, and Apple’s Siri are the leading general-purpose VAs. Other VAs are available, but these tend to be more limited in functionality and focus on supporting a single product or a service provider’s app. According to ZDNet, of the solutions from the big three players, Amazon provides the highest level of compatibility, supporting around 7,400 brands. By comparison, Google supports around 1,000, while Apple remains the most exclusive, supporting about 50.

Little Room for Voice Assistant Newcomers

With such powerful industry players already established on the market, there is little room for newcomers, and the technology curve to develop a competitive VA is significant. Thus, if you want to leverage voice control for your IoT solution, you have to play according to the rules set by the big three. An alternative approach would be to license a VA. However, some manufacturers questioned reported that licensing conditions were restricting their choices. These ranged from exclusivity or restrictions to stop more than one VA being used concurrently to licensing that forced the inclusion of other types of software or applications, meaning the VA technology couldn’t be used standalone.

Another big concern is access to data. As a third party relying on a VA, you only have limited access to the data collected. The VA provider has access to the audio recordings and would also know how many failed attempts there have been to issue the commands selected for your device. However, your team will not be provided access to the audio recordings, so you’ll more likely have to wait for user feedback to discover that your choice of voice commands is suboptimal amongst a group more expansive than that used for testing. Additionally, because the VA provider can analyze everything spoken into it, they could conceivably use this data to develop a solution that competes with yours or leverage user experience provided by your IoT solution to improve their services.

A further issue arises when the VA provider also offers advertising services. Theoretically, the voice input provided by your users could help the provider target advertising more accurately to the demographic represented by your customer base.

Finally, there is the loss of brand recognition and experience. Your carefully crafted solution is at the whims and mercies of the VA. Should they choose to make a significant change, such as the voice used, the wake word, or even roll-out functionality changes that result in a drop in users, you’re inevitably going to suffer the consequences too.

The report also examines many other relevant areas, including application programming interfaces (API), standards, interoperability, the imbalance in power between many third-party IoT device developers and the big cloud platform service providers, and contract termination clauses.

There are no recommendations in the report. However, the conclusions state that the report’s content will contribute to the Commission’s standardization strategy and feed into the legislative debate on the Digital Markets Act (DMA).

Security Concerns Worry IoT Implementers

Reviewing the data collected in Microsoft’s IoT Insights report, it is IoT security that is high on the list of worries. This issue is of particular concern for those planning IoT solutions, with 29% indicating that the associated security risks are holding them back from using IoT more. The report also explains that around a third of organizations are concerned about the security risks of IoT, especially data breaches. To combat this, outsourcing is highlighted as the best way of improving peace of mind.

While many engineers know the phrase “obscurity is not security,” few are skilled enough in this domain to ensure a solution is protected, end-to-end, from attackers. And while semiconductor suppliers offer a range of single-chip security solutions, developers still need to understand how to use them correctly to ensure that they don’t inadvertently introduce new security weaknesses.

Over the past decades, low-power wide-area networks (LPWAN) solutions such as LoRa and Sigfox have established themselves as key wireless IoT technologies supporting long-range communication. Achieving ranges of tens of kilometers, they are an alternative to cellular wireless such as LTE Cat-M1 and NB-IoT thanks to their superior low-power performance for low data volumes. But how secure are they?

LoRaWAN Under the Magnifying Glass

LoRa and LoRaWAN have been subject to particular scrutiny by the security and hacking community. Sébastien Dudek of Trend Micro, a company focused on IT security solutions, is one of several researchers that has written extensively on some of the potential issues. In a series of three technical briefs (brief1, brief2, brief3), he outlines a range of issues in the implementation and potential attacks. These range from denial of service (DoS) (Figure 1) and eavesdropping to bit-flipping (Figure 2) and spoofing of acknowledgments (Figure 3). The outcomes of such attacks range from the inability to communicate with nodes and reducing the battery life to altering application data.

Many of the vulnerabilities highlighted were resolved between version 1.0.2 and 1.1 of the LoRaWAN standard. However, further challenges arise when operating LoRaWAN nodes with gateways using different versions of the specification. In such cases, there is a need to make modifications to ensure secured backward compatibility between end devices and the back-end, as highlighted in a paper from 2018 by Tahsin C. M. Dönmez.

Beyond hacking the wireless link, there is also the issue of bad actors stealing and directly attacking the hardware. Sébastien Dudek also examines this aspect of security. In the case of LoRaWAN, many solutions use a microcontroller (MCU) and a Semtech wireless module. As these are connected via SPI, data passing between the two can be easily captured and analyzed.

Beyond this, there is also the issue of the security of the MCU itself. One attack method simply extracts the firmware from flash memory, allowing the code to be analyzed. If the security keys are also in the firmware, an attacker can use them to develop nodes that spoof authentic end devices. The recommendation to counter this is the use of Secure Elements (SE), single-chip authentication devices that securely store encryption keys. An approach using Microchip’s ATECC608A is one of several for which example code is available. However, while example projects demonstrate how to protect the cryptographic keys, the secure boot feature of this authentication device is not used. Thus, if the same approach were used for a product, the authentication device could be removed and used as an SE with a different MCU and new firmware.

Security Issues Across the Board

LoRaWAN end-devices provide only limited data bandwidth and, as they have no IP address like a Wi-Fi module, they are not addressable. As such, they offer minimal risk to corporate networks. However, potential risks lie with applications based upon such wireless technologies. These can have implications on lives and the environment should something goes wrong. For example, as part of a smart city network, LoRa-based sensors may be responsible for monitoring water levels to avoid flooding. If the data from the sensors are blocked, flood defense systems may not respond. Conversely, false injected data could result in flood defenses responding to an event that isn’t happening with potentially equally disastrous consequences.

And while LoRa and LoRaWAN have been highlighted here, plenty of researchers are examining other LPWAN technologies, including Sigfox and NB-IoT. In a paper by Florian Laurentiu Coman et al. , several proof-of-concept attacks on wireless networks in addition to LoRaWAN are described. In a technical brief issued by Deutsch Telekom it was stated that implementing Sigfox and LoRaWAN “without [an SE] can [even make] end-to-end encryption useless.” It explains that, by contrast, NB-IoT benefits from long-proven LTE security features, such as authentication and secure key generation and exchange. However, it also makes clear that end-to-end encryption is not standard and, if deemed necessary, must be discussed with the network operator.

Delivering City-Wide IoT Solutions

Concerns regarding security in LPWAN networks influenced technology choices made by DEUS POLLUTRACK Smart City GmbH i.G. for their IoT platform. Their team has been developing IoT sensor networks to monitor particulate matter in cities for more than a decade. With the technology deployed in more than 15 European cities, it enables local leaders of municipalities to make informed environmental decisions regarding air pollution. Their patented optical particle counters (OPC) are capable of monitoring down to the ultrafine particle (UFP) classification (under 0.1 μm). While larger particulates, such as PM₁₀ are considered dangerous for the lungs, UFPs can enter the bloodstream and pass to other organs through inhaled air.

DEUS’s sensor technology (Figure 4) uses a combination of stationary and mobile sensors, networked to back-end dashboards that visualize the data collected. Cities such as Marseille and Paris use 40 stationary sensors complemented by 300 mobile sensors. Mobile sensors are fitted to vehicles of partners, such as the delivery vans of DPD, that are already frequently underway in the target city. These sensors recalibrate themselves against data acquired by the stationary sensors they pass to ensure the accuracy required based. All this requires a robust, reliable, and secure LPWAN choice.

Talking to co-founder Marc Nodorft, he explains that both Sigfox and LoRaWAN were considered during the early development stages. Sigfox offered connectivity infrastructure, simplifying system deployment, but neither provided the data throughput required. LoRaWAN, at the time, wasn’t secure enough out-of-the-box and, without infrastructure partners in the cities where the technology was to be deployed, it would be necessary to deploy gateways that connected to the back-end via cellular networks. As a result, 4G and, later, 5G cellular were selected, resolving the issues of coverage, reliability, and security to the levels required.

Nodorft also tells us that, while there are plenty of cheap electronic solutions for IoT available, these are not robust enough for long-term deployment in the environments where their products are installed. Hence the choice was made to develop according to industrial standards, another consideration for those planning their own IoT products.

Another aspect is the back-end operations, which they have developed specifically to the needs of their IoT implementation (Figure 5). Moving forward, there is a need to support open-source reporting dashboards to allow government bodies using the system and citizens to access the data, which requires a cloud services provider. And, while there are plenty of choices, the provider is considered as important as the technical solution. Thus, the search is on for a provider that can provide personal support and not just an impersonal customer service chatbot.

With so much experience in significant IoT deployments and learning much about the technical challenges, I wondered what other advice Nodorft could offer those seeking to implement IoT solutions. “We’ve always stayed true to our vision,” he replies, “which has often required us to change the approach.” This has meant evaluating different technologies, working with different partners, and modifying the sales strategy on their road to success.

Teams of Experts and Partnerships Required

Looking at the available IoT landscape, it is clear that business opportunities abound, regardless of whether you are focused on solutions for consumers or industry. However, the journey from concept to deployment is fraught with challenges. While embedded systems developers may be well versed in hardware and firmware development, and may even have experience in wireless technologies, IoT and its security and scalability challenges may be too much for an organization to tackle alone.

According to the European Commission’s report, large organizations also have the upper hand in business relationships when it comes to services and platforms. Small players and startups will struggle to get the support they need in these asymmetrical relationships if they go it alone. Without a doubt, expertise, either hired or loaned, is essential to move beyond example applications, demonstration dashboards, and test IoT services. Finally, it is vital to fix your vision while remaining agile in all areas of implementation, from technology choices to target market, to fulfill it.
 

Questions or Comments?

Do you have technical questions or comments about this article? Email the author at stuart.cording@elektor.com or contact Elektor at editor@elektor.com.