Living in a connected world is a marvel, explains KARL JONSSON, but the LED lighting sector will need to evolve to IP-based networks that extend to the end node for smart lighting to reach its potential.

We are living in exciting times - Internet connectivity has already evolved from stationary devices to miniature interfaces in our pockets, with everything around us soon to be connected as we enter the era of the Internet of Things (IoT). You could argue that IoT-enabled products are available now, as we can already control our lights, thermostats, shades, and other "things" over the Internet. Today, we can collect sensory data from devices such as activity trackers, connected scales, and energy meters for analysis that provides consumers with new value-added services. Moreover, demand for smart buildings is escalating the demand for smart lighting. Professional lighting - pervasive, powered, and connected - is playing a key role in building the infrastructure for implementing IoT applications. As a specialist in professional lighting components and systems, Tridonic believes the market is moving quickly to demand integration of high-quality lighting with controls and sensors in smart, automated building systems, as building owners, facility managers, and occupants grow more aware of the value these systems deliver. Still, questions remain as to how solid-state lighting (SSL) systems will be connected in an interoperable manner, although IP (Internet Protocol)-based communications to the end node will ultimately prevail.

Interested in articles & announcements about IP networks & smart lighting?

A low-power wireless mesh network combined with wired options such as Power over Ethernet (PoE) enables Internet Protocol (IP) connections to end nodes in the net4more smart lighting platform.

IoT roadblocks pose challenges

State-of-the-art IoT solutions possess some major roadblocks that must be addressed before we can fully embrace networks of IoT devices beyond vertically integrated proprietary gadgets and closed ecosystems. This is especially vital for the professional lighting market.

The "things" part of the IoT vision typically comprises small, constrained devices that serve a narrow purpose, with limited or no interface. These could be anything from light bulbs with wireless connectivity for controls to battery-powered heartbeat monitors attached to your wrist. The term IoT may be fairly recent, but users wanting to connect their things is nothing new. Back in the 1970s, people were using the X10 protocol to control their lights remotely using simple analog-modulated signals over their power cables. Then infrared (IR) control became popular and, eventually, radio frequency (RF).

Z-Wave was one of the first modern-day protocols to gain significant traction with hundreds of interoperable products available in the market starting around 2005, from vendors that included General Electric, Leviton, Cooper, Jasco, and others. The Z-Wave Alliance specified and standardized a mesh-based sub-gigahertz (GHz) networking layer with a few application objects that organically grew over time to accommodate new devices and features.

ZigBee was a fast follower, with a 2.4-GHz networking layer also based on mesh routing. However, ZigBee's application layers were categorized into buckets for different industries, creating high market fragmentation with little to no interoperability. As a result, it took years for ZigBee to become a recognized player in the consumer market, but its customization capabilities sped its adoption for business applications. Newer rivals include the fast-growing Thread protocol and mesh network-based Bluetooth Low Energy (BLE).

Gateways, or not?

Another less visible problem with state-of-the-art IoT devices and protocols is the need for gateways to interface with end devices. Consumers' phones are typically used as a gateway to bridge the gap between a consumer device and an Internet service, but this is not ideal for business. In other cases, energy usage is being monitored by smart meters grouped in small networks (e.g., 200 households/smart meters per group), which interface with a gateway installed in the street to bridge the gap to a cloud server via a cellular network. However, in an office building, there may be hundreds of gateways interfacing with thousands of sensors and lights; thus, bridging islands is not a viable option.

At first glance, this might not seem to be a problem as multiple translation layers between different protocols can do the job, in theory. But imagine that a connected luminaire or sensor were to become a data carrier serving the Internet to other devices in its line of sight using Wi-Fi, Li-Fi, or other forms of high-speed wireless communication. In this case, translating packages in a gateway wouldn't be an option. In another scenario, where new sensors or applications need to be supported with existing infrastructure, all gateway firmware would require constant updating to support wrappers and translations for new function calls. Managing firmware and interoperability and, at the same time, complying with standards would become a nightmare. As an analogy, imagine you had to update your Wi-Fi router every time Microsoft released a new version of Office or every time you added a new device to your Wi-Fi network. Not a pretty picture, is it?

The problem with using gateways is not just supporting a wrapper/translation layer, but that things could get lost in translation (e.g., application programming interface [API] calls might be interpreted in slightly different ways from gateway to gateway). In large networks, it could also cause serious race conditions, resulting in system failure if state integrity on each side to the gateway can't be ensured. Finally, terminating an application call in the gateway before the end node can leave open doors for hackers to execute man-in-the-middle attacks, as the end device cannot ensure the integrity of the message.

In many cases, gateways with lightweight protocols are preferred, as IoT devices are typically constrained with limited processing power, memory, and encryption capabilities. The devices are often powered by battery or energy harvesting, so power management is crucial. All of this makes it hard to support a direct connection with the appropriate level of security.

IoT and professional lighting

The professional lighting industry is embracing the IoT and will play a significant role in becoming the IoT backbone. Why? Because lighting represents the largest network of powered devices in the world, and with the transition to LED lighting, this network is now digital, permitting easy access to power and connectivity for sensors and beacons. Embedding sensors and transceivers of various kinds into the luminaire design allows for new services beyond light such as space management, energy management, asset tracking, inventory/consumable tracking, and other capabilities that we've yet to imagine.

The most obvious solution is to base IoT devices on the IP, enabling them to communicate like our laptops and phones. Microcontrollers and system-on-chip (SoC) ICs have evolved quickly, so memory, processing, and security requirements are becoming less of a problem.

New protocols such as Thread permit IP communication directly to end devices using 6LoWPAN (IPv6 over Low power Wireless Personal Area Network) for low-power devices. The figure depicts one example of such a network, Tridonic's net4more platform. This is a promising development and much needed for standardization. In my opinion, the Thread Group made a brilliant decision to leave the MAC (media access control), PHY (physical layer), and Application layers out of the Thread requirements to allow ultimate flexibility and focus on the core problem. Leaving MAC/PHY optional would theoretically enable Thread to run on any wireless or wired network medium, such as Bluetooth, Wi-Fi, cellular, Ethernet, PLC, MoCA (multimedia over coax - home TV cable connections), and others, although they are starting with the wireless 802.15.4 MAC/PHY also used by ZigBee.

Leaving the application layer out of the specification allows an object model of choice, which is flexible but doesn't help with the interoperability problem. A few options are emerging, however, to help solve this problem. One is the recently announced DotDot standard from the ZigBee Alliance that reuses the existing object model or Cluster Library from ZigBee based on years of contributions from several industry leaders. In short, this permits the existing ZigBee Cluster Libraries to run on top of any networking layer and would complement networking standards like Thread. Progress in this area should continue to be monitored.

Conclusion

It's inevitable that professional IoT networks will eventually become IP to the end node. However, it will be some time until we can see the true benefits of horizontally integrated, fully-scalable IoT solutions since the technology and standards are still evolving. The key is to approach an IoT architecture with the right vision but allow for pragmatic design steps to achieve the eventual goal; shortcuts to speed market adoption should thus be approached with caution. The key mindset must be to follow standards that share the vision of communicating directly to the end node without wrappers and translation layers to ensure security, reliability, operational efficiency, and, in the end - and most important - true customer benefit and satisfaction.

KARL JONSSON is vice president of Internet of Things at Tridonic (tridonic.com).