BUTLER’s vision for system/device management in IoT

(extracted from Deliverable 3.1 of the BUTLER project: www.iot-butler.eu)

This document describes BUTLER project’s approach to the system/device management issues for resource constraint IoT devices. Section 1 introduces the state of the art in the domain. Section 2 presents some of the requirements identified in the project and the relevant architectures that would respond to these requirements. Section 3 describes a simple management information model that will be used to perform management actions on the IoT devices.

1.  Academic research on system/device management

BUTLER platforms will be composed of a large number of smart sensing and actuator devices such as temperature/humidity/luminosity sensors, light intensity regulators, parking space detectors, audio-visual devices, leakage detectors, valves, chemical sensors, GPS devices and RFID readers. Initially used by experimental applications, these tiny devices are now being used in more critical applications having better quality of service, dynamic adaptability and re-configurablility requirements in various domains such as home/building, industrial, transport, city and medical domains. Efficient remote management mechanisms are crucial to fulfill these requirements, enabling for instance remote deployment of software modules, (re-) configuration of device parameters and monitoring performance of devices, etc. Such management features would be used by:

- manufacturers to install the latest firmware when a new outdated sensing device detected in the environment.

- service providers/integrators to detect available devices and propose new applications or reconfigure existing ones

- end-users/administrators to have a view of the whole system. They can dynamically reconfigure network, system or application parameters; monitor performance of devices; and perform diagnostic or maintenance actions (ping, reboot, etc.).

Management of a great number of heterogeneous networked sensor/actuator devices is a very challenging task. Existing management mechanisms should be adapted and tailored with respect to the particular needs of networked sensor/actuator devices.

Management consists of configuration, monitoring and administration of entities such as network elements, system resources, applications or services in order to increase their efficiency. According to the type of entities, we can traditionally identify three main management domains: network management [NetConf], system management [WBEM] and application management [WSDM].

However, the boundaries between these domains have been progressively disappearing, since the emerging new generation networked smart devices are integrating these three functionalities, devices integrating network, system and application capabilities. Therefore, integrated management solutions are increasingly being developed. Next subsection gives a brief introduction to such solutions recently emerged in the device management domain.

Integrated management protocols - Device management

The number of connected devices is constantly increasing. Devices such as mobile phones, internet gateways, set top boxes, storage devices, lighting devices, print and copy devices are pervasive in home, urban, car or office environments. They are mostly capable of wirelessly communicating and powerful enough to host relatively complex systems with applications running on them. Remote management of these devices is becoming an important problem, in particular in multi-user, multi-manufacturer and multi-provider environments. These increasingly intelligent devices need integrated management solutions providing network, system and application management (see the figure bellow).

Device management is a generic term used for technology that allows third parties such as operators, service providers or manufacturers performing management actions on devices on behalf of the users. Through device management, an external party for instance remotely modify device parameters, perform troubleshooting and diagnostics servicing of terminals, install/uninstall/update software.

Figure 1. Device Management overview

Standardization efforts have been already made to allow remote configuration of network parameters, firmware upgrades, performance monitoring and software provisioning in different kinds of networks such as broadband networks [BBF], mobile networks [OMA-DM] and home networks [UPnP-DM]. However there are no such protocol yet defined in sensor networks or IoT domain.

Current research in sensor network management is area specific (i.e., network, system or application management). This section makes an attempt to classify the existing work in order to identify the management needs of each category and propose an adequate integrated management solution.

Network management. MANNA [Ruiz03] is probably the first work proposing a management framework for sensor networks. It defines management services (e.g., network monitoring service) using management functions (e.g., coverage area supervision) based on information models (e.g., sensing coverage area map). It adopts a manager-agent model. To the best of our knowledge, no functional prototype is implemented. Guerilla [Shen03] is another framework based on the manager-agent model, proposing an adaptive network management solution for ad hoc networks. More specific research work are also done concerning energy-efficient and adaptive reconfiguration [Cerpa04] and routing [Al-Karaki04].

System management. TinyCubus [Marrn05] aims at providing generic management mechanism with a particular focus on system software update. Similarly, MOAP [Stathopoulos03] proposes a reliable code update mechanism for Mica2 nodes. [Sugihara08] gives a synthetic survey on different sensor system software management solutions. Dynamic reconfiguration [Kogekar04] and performance monitoring [Bae06] are other system management related research areas. As above-mentioned examples show, dynamic reconfiguration and code updates are two important aspects of sensor system management.

Application management. Advances in embedded software management allow dynamically deployed applications on sensors. Applications may take different forms depending on the execution environment: scripts on virtual machines [Levis02], software bundles on modular environments [Liu03], queries on query processors [Madden05] and mobile agents on middleware [Fok05]. We believe that next generation IoT devices will be increasingly powerful providing such modular application deployment and execution. Sun SPOT sensors [SunSPOT] and mica motes [MICA] are two examples.

To the best of our knowledge, there is no existing integrated management framework incorporating network, system and application management for networked sensing systems. However it is worth to note that a new mailing list on “management of constrained networks and devices” has very recently been created in IETF aiming at discussing the requirements for such a protocol [COMAN]

1.1.1.  BUTLER system/device management requirements and architectures

This section presents management architectures specific to each application domain that we deal in the project. The objective is to define an overall architecture that would satisfy the requirements that have been identified during the requirements analysis phase in the Workpackage 1.

1.2.3.1.  Smart Home

Based on the selected smart home scenarios, following management requirements (Table 46) have been identified.

SH1Req3 / The system shall let users define thresholds / To notify the user when events occur / R / Functional
SH1Req4 / The system shall detect the sensors and configure them automatically / to discharge user of manual configuration / M / Functional
SH2Req3 / The system shall provide information on available controllable heating appliances / to make users or applications aware of the existance of those appliances / R / Functional
SH2Req6 / The system shall let user opt out certain appliances to be used for temperature regulation / To avoid controlling unwanted devices / O / Functional
SH3Req7 / The system shall detect the monitoring modules and configure them automatically (associate with a device, etc.) / to discharge user of manual configuration / M / Functional
SH3Req13 / The system shall detect the sensors and configure them automatically / To discharge user of manual configuration / M / Functional
SH4Req7 / The system shall detect the devices and configure them automatically / to discharge user of manual configuration / M / Functional
SH4Req8 / The system shall provide interoperable functionalities over heterogenous networked devices such as registration, announcement, discovery / To have interoperable objects and to manage them from the networking point of view / M / Functional
SH5Req3 / The system shall let device manufacturers and service providers send notifications to users (new service features, updates available, etc.) / To inform users about about new services, functionnalities or useful tips / R / Functional
SH7Req6 / The appliances shall be able to communicate with the system without configuration from the user / To minimize the user configuration effort / M / Functional
SH8Req1 / The system shall detect when a new device joins to the home network / to further configure the devices / M / Functional
SH8Req2 / The system shall know the configuration capabilities of the devices / to have knowledge on which configuration actions can be performed / M / Functional
SH8Req3 / The system shall be able to modify the configuration of the devices / to configure the device / M / Functional
SH8Req4 / The system shall trigger notifications when the configuration of a device changes / to notify users, manufacturers or service providers / R / Functional
SH8Req5 / The system shall save a configuration for further recovery / to discharge user of manual configuration / M / Functional
SH8Req6 / The system shall provide interoperable functionalities over heterogenous networked devices such as registration, announcement, discovery / To have interoperable objects and to manage them from the networking point of view / M / Functional
SH8Req7 / The system shall be able to communicate with all home devices in order to automatically install drivers on the devices remotely / To support auto configuration and management of devices / M / Functional
SH8Req8 / The system shall be able to ask to any devices and services about their status / To receive feedback about the success of the installation procedure / M / Functional
SH8Req9 / The system shall allow the user to provide feedback about configuration questions through a web based application / To receive feedback about configuration / R / Functional
SH8Req10 / The system shall detect and set up any new devices or services in an interval of time less than 1 minute after having been switched on / To avoid long waiting times / R / Non-functional
SH9Req3 / The system shall detect and configure automatically the devices that give the location information / to use different types of location sensors / R / Functional
SH9Req8 / The system shall be able to reserve ressources (content, tuner, bandwidth) for a given user / To ensure content is still available after the move / M / Functional
SH9Req11 / The system shall standby/resume a device / To activate only necessary displayers and to avoid unnecessary energy consumption / M / Functional
SH9Req22 / The system shall support control back to the user at any time / To have user control / O / Non-functional

We observe that the requirements are mainly related to 2 main actors in the smart home ecosystem: end-users and third parties such as device manufacturers, service providers and operators. For instance,

-  End-users

o  need to monitor the state of home devices and manually configure some device, system and application parameters

o  besides the possibility of manual configuration by end-users, devices should be automatically configured, provisioned and ready to be used in order to discharge the user from complex configurations

-  Third parties (device manufacturers, service providers, operators, etc.)

o  need for monitoring, configuration and updates to deployed devices and services

o  need for discovering existing devices and services at home and to provide complementary services to the existing ones

Users wish plug&play configuration facilities, rapid resolution of problems and awareness of what is going on in the system, while third parties (service providers, operators, manufacturers) desire to provide better quality of service, personalized and automatic customer support, and customized offers to the users based on their profiles. In terms of architecture, we can thus separate 2 main management architectures: a local management architecture that responds to the first class of requirements and a global one for the two latter classes of requirements mentioned above.

1.2.3.1.1.  Local monitoring and configuration of devices by end-users

Figure 2: Management architecture for smart home scenarios involving end-users

In this architecture, the user can monitor and supervise the home devices by using a management console that can be executed on a PC, tablet or a mobile device. All management actions should be performed by some management agents that will provide homogeneous access to underlying heterogeneous set of devices. Management Agents are in charge of performing the management actions on behalf of the user. Typical management actions are configuring devices, updating them with a new firmware, rebooting them or monitoring their performance parameters such as battery level, lost packets, etc.

1.2.3.1.2.  Remote monitoring and configuration of devices/service by third parties

Figure 3 : Management architecture for smart home scenarios involving third parties

In this second architecture, besides user management, the authorized third parties can also monitor and supervise the home devices by management tools that are hosted on backend servers. Management tools can bring great advantages to the third parties in terms of:

-  continuous maintenance by remotely monitoring devices for fault detection, bug fixing, etc. , and performing diagnostic operations

-  continuous improvement of devices and services by regular updates or customized offers

-  cost reduction by adding autonomic management features and avoiding costly telephone based customer support ; reduced time-to-market for applications thanks to the remote deployment features

However in order to obtain an efficient management tool there are some major main challenges to consider, which are:

-  Scalability: Efficient tools are necessary to handle the great number of devices deployed in home and the rapid response time requirements of users.

-  Heterogeneity: Devices will be of different providers communicating with different protocols. A unified management protocol is needed to

-  Security: Only authorized entities should be allowed to perform management actions.

-  Governance: In case several entities are involved in the life cycle of a device, the owner of the device, service executing on the device and the data that are generated should be clearly identified.

-  Constrained resources: for battery powered tiny devices resources should be used efficiently, thus heavy management mechanisms should be avoided for these devices.

Several management protocols exist for home devices such as TR-069 from Briadband Forum and UPnP DM. The proposed management mechanism should provide bridges and adapters to these protocols. Therefore the architecture should be compatible avec those protocols to facilitate adaptation.