Group Management for Capillary Networks

by OMA | Friday, May 8, 2015

Group Management for Capillary Networks

May 7, 2015 | — As the Internet of Things (IoT) becomes a reality, large numbers of very heterogeneous devices will have to be managed. How can this be done in the most efficient way?

This type of device management will expand, not only to automated software updates or error reporting of the devices, but also about how do they interact with their surroundings, with people and with other devices. That type of management will be based on the actual semantic properties of the devices. Moreover, features like energy consumption, processing power and network efficiency will be important than ever. In this context, the problem of how to manage different sensors on different locations at once becomes paramount; one single extra message per device can greatly increase network congestion.

As we wrote in our Evolved Capillary Networks blog, we initially focus on two key aspects;Distributed Cloud and now Group Management.

For the case of group management, there are already many solutions available. Without going through all cases, in its most basic form, a unicast solution is used. That is, a manager has to address every single device when it wants to update/read some information on it. Normally, the device would register with a server and share its network location information, often in the form of a URI or IP address. If necessary, after setting some NAT traversal mechanism, the manager will simply send messages to the device. So if a group is created, the manager still has to send a message to each of the members of the group; conversely it will get all of the raw updates from each device too. These types of systems do not scale well for millions of devices.

Other solutions handle devices as network elements, relating them to the network or subnetwork they belong. Problems can be solved by addressing different devices as if they were in different subnets. Take for example all of the devices inside one room, they are provably under the same gateway; therefore they can be addressed as a different subnet using, for example, IP (v4 or v6) multicast. Similar solutions working on IPv6, together with application layer protocols like CoAP on top, can provide group addressing. These solutions associate an IPv6 multicast address to a group. The problem with this type of group communication is that it offers limited reliability (same as IPv6 multicast). It can also cause lots of responses from different devices and require some control through other mechanisms.

However, in other cases, you will have various deployments with devices on different subnets, using different network layer protocols (IPv6 or IPv4) and different radio technologies (BLE, Wifi, ZigBee, LTE, etc). For those scenarios, we propose using the semantic information of each of the devices to create groups. Those groups could be done based on any of the attributes a device has; let it be location, sensor type, manufacturer or others.
Attributes define a group. When a manager or a device creates a group, it sets a logical relation between a set of devices and causes them to listen/subscribe to notifications on those groups. This way, you might have devices of different vendors, which do the same function, actually listening to the same group. When updates from/to devices occur, they are sent in a very efficient manner, with minimal message overhead, aggregated and prioritized according to importance.

We have created a proxy node for management commands that can queue those commands if the device is asleep as well as aggregate responses to greatly reduce the network traffic. Moreover, if devices are not using IPv6, the proxy can also help to bypass NATs and forward messages to both the manager and the devices. Additionally, we can also prioritize commands in the queue and discern whether they are outdated, super-seeded or simply no-longer-relevant and drop them in those cases.

This functionality can be implemented in several ways, for the semantic interoperability we chose IPSO Objects, since they provide a standard way to structure the device’s data. For the management we chose OMA DM Lightweight (LWM2M), therefore we were also using CoAP. We also chose to perform the subscriptions as CoAP commands with the Observe option enabled. Regardless of the protocol selection, the main issue would be to provide the aggregation and brokerage functionality to handle groups of devices.

For the Mobile World Congress demo, we showed the Group Management functionality with a simple light management system. There was a set of independent lights on different subnets that could be controlled from our web interface. A visitor could address each of them individually–or choose to create a group of some of them. The group option was made based on location, by dragging the mouse to define an area on the map and then selecting the devices within that area. Those devices were automatically assigned to a group. Since they shared the same semantic properties of a light (i.e. switch on/off), they could be simultaneously switched on and off as a group. Of course in the real world, the number of devices would be much greater and the groups could be made on arbitrary properties of them.