Gateway solution for IoT

More and more OEMs start to connect their products online, the first issue that comes is connectivity to the Internet. One might want to connect a rice cooker so you can remotely start cooking and have it ready when you get home, or enable some fancy machine learning algorithms to your home appliances so they would remind you to gain more exercises, sleep early, monitor your health status by collecting your activity at home. As an OEM, you can partner with an IoT platform, integrate a wifi chip to your device, probably add more processing powers, memory, in case you want some extra smart features(Firmware update ability, security, etc), then connect to the cloud and there it is, you get a cool connected product. However, each feature comes with a cost increase, a customer of yours might not really care about all the add-ons you provide, I don’t  want to spend 100 extra dollars to equip my light bulb with state of the art processor to make RESTful HTTP request or conduct complex over the air firmware update in a tailored unix operating system running docker. As an end customer, all I care about is that my light bulb correctly receives my cmd and sends status to me.

That’s where a gateway solution comes in. A gateway offers shared computing resource for multiple nodes, thus significantly lowers the complexity and cost to each individual device.

A gateway understands WiFi and handles all traffic between nodes and the cloud, mobile. Your light bulb doesn’t have to understand any TCP/IP protocol, not even Bluetooth, just plug your light bulb into a power interface provided by the gateway, now your gateway knows whether or not your light is on and can control it by turning on and off the power on the power endpoint. Now if you have ten light bulbs, you don’t have to add WiFi hardware support for each of them, just plug them all to your gateway.

A gateway should be generic to many different protocols. Think about a Low Power Bluetooth connected battery powered door sensor? Use a gateway that supports Bluetooth, and leave only the simplistic computing job on the door sensor itself, thus lowering power consumption, hardware requirement, integration simplicity, expertise to develop WiFi stack, etc. Now extend to even more: Zigbee, ZWave, Bluetooth, Ethernet or even ADC to get voltage based sensor data.

What if your internet goes down? Well, as long as there is electricity, you still have control of your light bulb through gateway inside your room, which is connected to your router. This brings another interesting topic: Where should the smarts go in a gateway model, should it be in the cloud or the gateway? The trade off is what you can provide to customer without internet connection. If more smarts stay in gateway, that adds more cost to every single gateway device, but provides more functionality offline. For example, if Zigbee details live in the cloud, you won’t be able to use mobile to control Zigbee connected devices without WiFi, plus that also brings extra time delay, causing customer experience issue, another workaround is to implement Zigbee details in mobile apps, which adds more implementation effort in iOS or Android.

How generic could a gateway be? Standards like Zigbee is understood by most manufacturers, but each IoT platform has its own representation of device.Interoperability at network level doesn’t really address application level problem, but there are various things we can do about it. Each device has an online shadow representation of itself, at Ayla we call it “template”, it’s like a blueprint of a device, specifying what functionalities a device has. Different standards also have similar definitions of functions, for example, in Zigbee, a cluster defines one functionality, on-off cluster means turning on or off something. On the cloud, these clusters can be manually defined into templates so the cloud understands the device. On the gateway, it can query the node in Zigbee protocol on what clusters it support, and send this information to the cloud to attach the new node with its clusters. The manufacturer of the node could input its functionalities to the specific IoT cloud so it’s ready to take the info sent from gateway, constructing the shadow device. Apart from this, there are other more generic features that a gateway need to handle for nodes, like connectivity of a node through gateway, over the air update. Some require specific implementation, some are generic to one standard. It requires careful data modeling on the cloud generic communication between cloud and gateway.

Gateway model also presents interesting performance challenge to the cloud. Unlike a one device to cloud connection, a gateway can represent many devices. For example, Zigbee standard allows over 60k devices with one gateway. Now imagine the gateway trying to report 60k devices’ status to the cloud in one request, or get commands from the cloud for all these devices, or mobile trying get all nodes’ information attached to this gateway. And if you multiply this number with the number of gateway the cloud supports, things can get into a mess. Well, it doesn’t have to get all of them in one request, but either way, it’s a trade off between number of request and amount of information in one request.

What about sharing a node with a friend of yours? With a one device to cloud model, the user authentication and authorization goes through the cloud, with a gateway model, shall the gateway also keep the user specific information for each node?

Gateway solution presents very interesting, open ended challenges. And the solution varies for different platforms. I’m only touching the surface here, will introduce more details in later post.