Having a headache using legacy IoT devices?
We have just what the doctor ordered!
At ETSI’s 3rd workshop on Machine to Machine (M2M) communications held in Mandelieu France, we presented how different devices can be wrapped and exposed as proper IoT devices, including a live demo.
For any IoT deployment, sensor and actuator devices are fundamental. Embedded technologies have been around for years, but the technologies used are very diverse. Interfaces, networking, and application layer protocols exist in many shapes and forms. This technology fragmentation is a fact, as presented in a previous blog post. For any deployment to grow into a true Internet of Things, this technology fragmentation must be overcome.
There are two possible paths: either standardization of new, universally acceptable protocols, or interworking and integration of these heterogeneous device technologies. One can, of course, discuss the feasibility of each of these two different paths. This time, we would like to let you know how we have explored the latter path, namely IoT device integration via IoT Gateways. We will come back to the former path in a later blog post.
Figure: Gateways in an IoT system context
Gateways are traditionally thought to bridge two different technologies on the interface level, e.g. to bridge an IEEE 802.15.4 based wireless sensor network to a wide area networking technology like cellular. Gateways can also be used to integrate a larger set of heterogeneous interfaces on one side to a uniform interface on the other side (see figure above). A lot of focus has been put on bridging legacy device networks onto the Internet, i.e. ensuring that IP can be used as the common networking protocol throughout. This is, of course, very good and definitely a step in the right direction towards an Internet of Things, but it doesn’t have to stop there.
Putting everything legacy on IP has many merits, but in the context of the Internet of Things, one part of the problem is just pushed “one level up”. How do we deal with different application level protocols, e.g. mixing both Z-Wave and ZigBee devices in a Home Automation context? We argue that gateways can even be used to “normalize” application level capabilities so that different legacy devices are exposed “northbound” from a gateway in a uniform way. Gateways could, in fact, also enable direct legacy device-to-device interoperability.
Now, some claim that if we use IP all the way down to a tiny IoT device (which we firmly believe is the right choice), there will be no need for gateways. “IPv6 can be used end-to-end and gateways are not needed.” We claim this argument can be true, but only if you consider the networking aspects. If you consider the wider context of applications, constrained environments with sensors running on batteries etc., gateways have many other roles. Gateways shield the resource-constrained devices from misbehaving applications that risk draining their batteries. They work as security perimeters between different domains. Gateways can cache and aggregate sensor readings. They can even host simple application logic like closed sensor-actuator control loops. So, the term “gateway” is a misnomer as it can, in fact, play a very important – if not critical – role in the context of applications.
It would very useful if one could normalize how the capabilities of various legacy devices are actually exposed to application developers and the cloud environment. After all, a smart plug is just a smart plug. It can provide capabilities like switching on and off, dimming and measuring current or power consumption. So, what you want to be able to do is to mix, for example, a ZigBee smart plug and a Z-Wave smart plug in your deployment without having to bother with it. Taking the devices and normalizing the way they are exposed via a single API to applications would certainly help. Of course, this API should be based on IP; it should be based on the paradigm of the Web itself; and it should have a simple and application-independent way of describing the capabilities regardless of whether it is a ZigBee or a Z-Wave device that is connected.
Well, this is exactly what we have in place. We have the way IoT devices should expose themselves as web devices, and we have our own defined framework for legacy device integration called Generic Device Access – GDA for short.
Figure: GDA as a framework to integrate diverse device technologies
GDA provides the capability of taking protocol specific functionality and mapping that into a service schema provided by the GDA framework. A base driver terminates the specific device protocol stack and, in particular, the application layer. A protocol adapter then adapts the specific device capabilities to the service schema framework used by GDA. GDA is based on a set of Java APIs, and runs in an OSGi environment. Once integrated into GDA, the device capabilities can then be exposed northbound via a protocol of choice. These northbound protocols are realized with so-called Connectors, and can be, for instanc,e Broadband Forum (BBF) TR-069 or Open Mobile Alliance Device Management (OMA DM) towards remote device management applications, or ETSI M2M mId towards M2M applications. With GDA, we have the freedom to support a range of southbound device protocols as well as a range of northbound protocols. Adding a new device simply means that you will have to write some Java code for the Protocol Adapter and then you’re done.
Specifically, when talking about “proper” IoT devices, as mentioned above, we imply using the Web paradigm. To this end, we rely on the work being done in the IETF CoRE working group. CoRE specifies how RESTful capabilities are brought to constrained IoT environments. In particular, the working group specifies a RESTful application protocol called CoAP as well as a set of capabilities like web linking of resources, discovery and so on. Also of importance is how the capabilities of the IoT resources are described, and that this is done in a simple way and ideally in an application independent way via an application profile. Being active in the IPSO Alliance (IP for Smart Objects), we have picked the IPSO Application Framework as the simple profile that ensures easy implementation and interoperability. The task of “normalizing” legacy devices to make them appear as “proper” IoT devices is hence about taking, for example, a Z-Wave device and wrapping that in a CoRE (i.e. a CoAP or HTTP binding) and applying the IPSO Application Framework to describe the exposed resources. Naturally, we argue that “proper” IoT devices will actually implement CoAP and a simple application profile like that of IPSO natively. The topic of these “embedded device web services” and the role of application profiles is something I think we will have to come back to in a later blog post.
Recently, ETSI arranged its 3rd M2M Workshop in Mandelieu, France. We were there to demonstrate this work. Our team had a joint presentation with Zach Shelby from Sensinode entitled “Embedded Devices on the Internet of Things”, where we demonstrated these technologies along with ST Microelectronics.
Figure: Demonstration setup
In the demonstration, we had a few “proper” IoT devices running CoAP in a 6LowPAN enabled IEEE 802.15.4 network, but also legacy Z-Wave devices in the form of smart plugs. All devices were connected to an M2M gateway from ST Microelectronics. The M2M gateway hosts an OSGi environment in which our GDA software is running alongside other software such as some of the IETF CoRE implementations. The gateway was connected to the Internet and towards an application environment where we demonstrated a few Smart Home-oriented services based on the Social Web of Things concept.
Sebastien Pierrel (center) with Fabien Castanier (right)
from ST Microelectronics at the demo stand
The demonstration also included key IETF CoRE functionality such as proxying and resource discovery and publication. We had 6LoWPAN/CoAP devices proxied to HTTP northbound, while the IPSO application profile was transparent. The Z-Wave devices were wrapped in CoAP which were also proxied to HTTP. Given the choice of CoAP or HTTP northbound, we picked HTTP, but could have also chosen CoAP. For our current purpose it does not really matter. Regardless of CoAP or HTTP, the native CoAP devices and the Z-Wave devices were exposed northbound with exactly the same API, so it wasn’t obvious what type of device was behind the gateway. This is good for applications and application developers, we think. We also had resource discovery and publication in both the gateway and in the cloud. This was done via the Resource Directory, which keeps track of which devices have what IoT resource capabilities.
Overall, the demo was very well received with lots of visibility. As a matter of fact, we also had the opportunity to run the same demonstration at the IEEE IoT Workshop held last week in Milan, Italy. This time our colleague Fabien Castanier from ST Microelectronics also gave a joint presentation on the subject.
We will continue our work on integrating IoT devices and will provide more news to you as things progress.
— Jan Höller, Sebastien Pierrel and Vlasios Tsiatsis, Ericsson Research