3500000000PCS LEDS PER MONTH
Booth:Hall 10. 2,A02
Gateways, or not?
Another less visible problem with state-of-the-art Io T 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 ( http://bit.ly/1ONns YF). 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 wrap-per/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 ( http://bit.ly/2pmZI Yn).
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.
Io T and professional lighting
The professional lighting industry is embracing the Io T and will play
a significant role in becoming the Io T 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/consum-able tracking, and other capabilities that we’ve yet to imagine.
The most obvious solution is to base Io T devices on the IP, enabling
them to communicate like our laptops and phones. Microcontrollers