Non-IP-based communications abound in the connected LED lighting space, but GIULIO BORSOI explains how gateways in such systems can introduce system performance issues, while IP-based protocols to the end node will eliminate such issues.
The Internet of Things (IoT) concept is exploding in commercial and residential sectors and across many product types, with LED-based lighting being one such example. Lighting is ubiquitous and powered and could be a perfect IoT backbone; solid-state lighting (SSL) fixtures increasingly leverage connectivity for automated control, preventive maintenance, and other applications. That said, there are issues that plague IoT progress across applications, a primary one being gateways that are often required for networking and communication between IoT devices. Information is often lost, however, during signal conversion. But a move to IP (Internet Protocol) communications all of the way to the end node is one way to optimize system performance and reliability.
FIG. 1. Many conventional connected-lighting systems utilize gateways to connect devices on DALI segments while an IP network links the DALI segments and other devices such as switches, tablets, and smartphones for control. The gateways create the potential for unreliable operation.
Indeed, the IoT is developing at a rapid pace. The number of connected devices is increasing all the time, not just in the private consumer sector in the form of household appliances and smart devices but also in industrial applications (Industrial Internet of Things, IIoT). This covers devices such as industrial PCs, smart cameras, sensors, and now luminaires. Like any technical network application, IoT is reliant on devices for connecting, handling, and transferring signals. These functions are generally performed by conventional gateways.
First, let's examine in detail the problems that gateways can cause in such systems. Then we will consider new technology that will enable modern lighting infrastructures to operate without gateways, delivering full IP communication directly to the luminaire and other elements of a smart lighting system.
Defining the gateway issue
In our context here, the term "gateway" does not refer to routers that act as the hardware interface to provide access to the Internet. Such routers operate at layer 3 of the OSI reference model (Open Systems Interconnection model; for background, see http://bit.ly/1C2UTQn). The routers require information on the network structure and transfer data packets on the basis of their IP header - without having to understand the contents of the packets.
Instead, what are relevant in our discussion here are gateways that operate at the application layer, in other words in layer five and above in the OSI model. For proper data communications, these gateways have to understand and convert the contents of the packets in their entirety.
For lighting infrastructures, this means that conventional control protocols such as DALI (digital addressable lighting interface) definitely need application gateways for communication because the time element is critical here. If the response to a request is not received within a certain time, the request will not be forwarded. Transfer of DALI frames is possible only with application gateways that are capable of interpreting the packet contents.
Lighting control with DALI
The question is, how does lighting control with application gateways work in a realistic DALI environment where an IP network connects many DALI subnetworks? The application program has to convert the properties of a button press, the number of events, and their duration into one or more DALI frames so specific luminaires can be controlled accordingly. It is not unusual for a group to include luminaires belonging to different DALI lines. In this case, Gateway A may have to forward the command to another DALI controller (Gateway B) using a different protocol to switch the light on (Fig. 1). An appropriate request is created and incorporated in an IP packet. Gateway B now receives this packet and initiates the activation of the appropriate luminaire. Gateway B converts the user request to DALI and consequently also the signals on the bus.
FIG. 2. Conversion to an IP-based, gateway-free architecture means that no gateways are required to deal with application-layer data, so only the instigator and target in a transaction need to understand the application-layer data.
Communication between the two DALI gateways must be specified for this to occur. If DALI were the only protocol and if the IP network were used as a practical basic infrastructure, the complexity of the gateways would not be a problem. Problems may arise, however, if the two gateways operate with older protocols in addition to DALI, such as DMX, 0-10V, or the protocol for KNX building automation. In this case, it may no longer be possible to control conversion of the data signals.
There is then an increased risk that entire data packets will be delayed or not transmitted at all because of timeout problems or incorrect addressing. For transmission within different protocols, there is a chance that individual requests may be converted into many different commands. The gateway now has to correctly interpret the commands according to the request, which is a challenge. If this process is not working properly, then important information may be lost during conversion. In extreme cases, this may result in the system failing entirely.
Lack of synchronization may also occur because not all manufacturers can equip their gateways with comprehensive functionality that supports all possible protocols. Often the sticking point in equipping standard gateways with certain features is that there was a lack of coordination in the process from development to market maturity. Proprietary features normally require functionality that is supported both by the user input and by the actor (in other words, by the controller or luminaires); if this is the case, lack of coordination is unavoidable.
In the case of an old protocol, these features should be supported by all the gateways that may be involved in communication, like all the protocols used. This requirement exists in stark contrast to IP-based architectures where the problem is solved using a much more complex structure of the communication protocol, which does not require gateways.
Completely eliminating gateways in the network
In view of these difficulties, it is worth considering whether and how gateways can be completely eliminated in networked infrastructures, in other words how a completely gateway-free architecture can be implemented. This is possible if requests are transmitted via devices that do not have to understand the contents (Fig. 2).
Here is an example that will explain how this gateway-free concept works. Host A generates a request within the application layer, which it intends to send to Host C. The former transfers the request to the network layer where it is provided with a header that contains the IPv6 address of the recipient. The packet is then forwarded to the MAC/PHY layer where a further header with the MAC address of the next hop (Host B) is added. Host B receives the packet, checks the MAC header, and transfers it to the network layer where the IP header is checked.
Host B determines that the destination address is not the same as its own IP address. At this point, it is important to understand that the header format and the content are fully specified by the network layer protocol, and completely independent of the volume of application data. The intermediate host knows that it must forward the request to another node and sends it to the MAC/PHY layer where the MAC address of the next hop is added and the packet sent on once more.
If this next hop is the intended recipient (Host C), it recognizes both the MAC address in the packet as well as the IP address in the header of the network layer PDU (Protocol Data Unit) as its own. The packet is then transferred to the application where it is interpreted and processed. The number of intermediate nodes the request passes through is of no significance. None of the nodes - except Hosts A and C - needs to understand the contents of the packet. Since only the end nodes need to understand the contents of the communication, they can easily secure them to protect sensitive information or authenticate them as genuine products. By comparison, an architecture that makes use of gateways for signal transmission can offer only limited security standards.
Lighting infrastructure as a basis for IoT
As described above, not only are gateways not needed for data communication but a gateway-free architecture also offers significant benefits such as avoiding conversion problems, which ultimately enhances the security and stability of the network. This also applies to the IoT - and particularly to lighting infrastructures, in other words the (IP-based) digital networking of luminaires.
Such networks are suitable as the carrier infrastructure for IoT applications for various reasons. As hinted at earlier, luminaires are already present in huge numbers - wherever people live, work, and travel, such as buildings, public squares, and roads. What's more, lighting systems already have their own integrated power supplies so there is no need for power cables to be laid or batteries to be provided. Luminaires normally also have sufficient space for sensors to be integrated, making them ideal as hubs for collecting and transmitting data.
Moving forward, lighting-based infrastructures can do without gateways with no problem at all. One option available to luminaire developers is the net4more toolbox developed by Tridonic. The toolbox combines various components such as LED drivers, communication modules, interfaces, sensors, routers, software, and applications to create a complete, well-designed connected system. The result can be a genuine IP-to-the-end-node implementation with IP packets delivered right to the luminaire.
Open and interoperable
Moreover, the proposed architecture is based on open standards and it's flexible and highly scalable. For example, the toolbox is based on the IPv6 open standard for Internet communications and enables wireless communication on a low-power version of IPv6 in accordance with the Thread standard. Luminaires based on the toolbox can be an integral part of the IoT and can communicate fully with other devices in the network. Furthermore, it's a future-proof hardware and software platform.
FIG. 3. The diagram of the OSI model shows how the net4more toolbox is mapped into the open-standards IoT environment, enabling reliable and scalable smart lighting systems.
As stressed earlier, the proposed concept does not require any gateways for networking the lighting-centric IoT components - and you need to understand that this statement applies beyond the luminaires. All the functions of the luminaires along with independent devices such as sensors and beacons can be addressed directly. This significantly reduces the cost of setting up, operating, and expanding the network and the application software.
The platform also makes use of standard technologies such as UDP/IP (User Datagram Protocol over IP), CoAP (Constrained Application Protocol), DTLS (Datagram Transport Layer Security), and LWM2M (Lightweight Machine to Machine). Fig. 3 depicts how the technology is layered into the OSI model.
The proposed architecture further supports European research projects initiated by leading players, such as OpenAIS (Open Architectures for Intelligent Solid State Lighting Systems). This project comes under the Horizon 2020 program and is in part financed by the European Union. Its aim is to create an open ecosystem for implementing smart lighting solutions so they can easily adapt to the different needs and requirements of people. Another objective of OpenAIS is to make efficient use of buildings with high levels of comfort for occupants and significant reductions in operating costs. The IoT will serve as the basic technology for the "Internet of Light."
A network that needs application gateways for communication will often have weaknesses. This applies also to IP-based networks such as the IoT if they need to interface to old systems such as DALI. The loss of information in signal conversion can adversely affect the security and stability of data transmission - and even lead to system failure. In lighting infrastructures, traditional control protocols such as DALI, however, are totally reliant on gateways to ensure communication. Modern concepts such as net4more, on the other hand, enable full IP communication as far as the end node and therefore make application gateways and associated error sources obsolete. The gateway-free architecture is therefore content-agnostic and supports any conceivable application based on end nodes without requiring any adaptation.
GIULIO BORSOI is a research engineer at Tridonic.
