Document Sample
BUTLER Powered By Docstoc
					     BUTLER’s vision for system/device management in IoT
             (extracted from Deliverable 3.1 of the BUTLER project:

This document describes BUTLER project’s approach to the system/device management issue s
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

          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
- 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

                              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
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

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.

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

                 The system shall let users define
   SH1Req3                                                To notify the user when events occur       R   Functional

               The system shall detect the sensors
   SH1Req4                                              to discharge user of manual configuration    M   Functional
                and configure them automatically

               The system shall provide information
                                                        to make users or applications aware of the
   SH2Req3       on available controllable heating                                                   R   Functional
                                                              existance of those appliances
                 The system shall let user opt out
   SH2Req6       certain appliances to be used for        To avoid controlling unwanted devices      O   Functional
                      temperature regulation
              The system shall detect the monitoring
                   modules and configure them
   SH3Req7                                              to discharge user of manual configuration    M   Functional
              automatically (associate with a device,

               The system shall detect the sensors
  SH3Req13                                              To discharge user of manual configuration    M   Functional
                and configure them automatically

               The system shall detect the devices
   SH4Req7                                              to discharge user of manual configuration    M   Functional
                and configure them automatically

              The system shall provide interoperable
                                                         To have interoperable objects and to
                functionalities over heterogenous
   SH4Req8                                              manage them from the networking point        M   Functional
                    networked devices such as
                                                                       of view
              registration, announcement, discovery

                   The system shall let device
               manufacturers and service providers
                                                        To inform users about about new services,
   SH5Req3       send notifications to users (new                                                    R   Functional
                                                               functionnalities or useful tips
               service features, updates available,

                 The appliances shall be able to
   SH7Req6    communicate with the system without       To minimize the user configuration effort    M   Functional
                  configuration from the user

               The system shall detect when a new
   SH8Req1                                                   to further configure the devices        M   Functional
                device joins to the home network

                   The system shall know the
                                                        to have knowledge on which configuration
   SH8Req2       configuration capabilities of the                                                   M   Functional
                                                                actions can be performed
              The system shall be able to modify the
   SH8Req3                                                       to configure the device             M   Functional
                   configuration of the devices
               The system shall trigger notifications
                                                         to notify users, manufacturers or service
   SH8Req4      when the configuration of a device                                                   R   Functional
              The system shall save a configuration
   SH8Req5                                             to discharge user of manual configuration     M     Functional
                      for further recovery

             The system shall provide interoperable
                                                        To have interoperable objects and to
               functionalities over heterogenous
   SH8Req6                                             manage them from the networking point         M     Functional
                   networked devices such as
                                                                      of view
             registration, announcement, discovery

                  The system shall be able to
             communicate with all home devices in          To support auto configuration and
   SH8Req7                                                                                           M     Functional
              order to automatically install drivers            management of devices
                    on the devices remotely

             The system shall be able to ask to any    To receive feedback about the success of
   SH8Req8                                                                                           M     Functional
             devices and services about their status          the installation procedure

               The system shall allow the user to
             provide feedback about configuration
   SH8Req9                                              To receive feedback about configuration      R     Functional
                questions through a web based

             The system shall detect and set up any
              new devices or services in an interval
  SH8Req10                                                    To avoid long waiting times            R   Non-functional
             of time less than 1 minute after having
                        been switched on
             The system shall detect and configure
   SH9Req3   automatically the devices that give the   to use different types of location sensors    R     Functional
                     location information
               The system shall be able to reserve
                                                    To ensure content is still available after the
   SH9Req8   ressources (content, tuner, bandwidth)                                                  M     Functional
                         for a given user

               The system shall standby/resume a        To activate only necessary displayers and
  SH9Req11                                                                                           M     Functional
                            device                     to avoid unnecessary energy consumption

             The system shall support control back
  SH9Req22                                                        To have user control               O   Non-functional
                    to the user at any time

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
           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, o perators,
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.

        Local monitoring and configuration of devices by end-users






                                      Agent (MA)   Home
                      end-user        console

         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.
       Remote monitoring and configuration of devices/service by
                           third parties

                        MA               MA




                                  Agent (MA)   Home gateway

                  end-user        console


                                                           Telecom                  Manufacturer
                                                           operator                 management
                   Service                                                          server

       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 t erms 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
    - 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.

   Smart Healthcare
The health care user stories that have been identified in the workpackage 1 belong to two
main themes:
   - Remote assistance
   - Personalized reminders and recommendation
Based on this user stories the main management requirements (Table 47.) are the following:

             The system shall allow authorized to allow for instance
             entities       to         update doctors to provide more
SHC1Req16    recommendations                   precise recommendations M        Functional   Task 3.3   CEA

             The system shall discover and
             configure       health      devices
             automatically     with    minimum to discharge the user from
SHC1Req17    intervention required by the user   complex configurations   M     Functional   Task 3.3   CEA

             The system shall allow the doctor
             to remotely control the camera To empower the doctor for
SHC2Req4     and microphone of the user        efficient system utilization M   Functional   Task 3.3   KU Leuven

             The system shall let to the users
             and/or caregivers to configure To adapt to the evolution
SHC3Req12    reminding periods                 of the patient         R         Functional   Task 3.3   CEA

             The system shall let users to
             configure      the   application
             parameters (enabling localisation
             information, list of contact to give the control to the
SHC4Req9     persons, etc.)                    user                  M          Functional   Task 3.3   CEA
These requirements well summarize the management needs in this domain for 2 main actors:
which are the end-users (patients) and caregivers (medical service provider, doctor, nurse,
family members of the patient, etc.)
   - End-users
          o need to install, initiate and calibrate the healthcare devices,
          o need to give remote access to information provided by the devices and assign
              authorizations to different entities.
          o when possible the configurations should be done automatically in order to
              discharge the user from complex configurations
          o need to configure applications (define alarm thresholds, periodicity, etc.)
   - Caregivers
          o need to discover available devices and acquire access to them
          o need to remotely monitor and configure device parameters
          o need to configure and update applications (update recommendations, etc.)

Healthcare domain has very specific and strict security and privacy requirements that should
be taken into account with care. For instance, contrarily to the home domain in which there
are several end-users (different occupants of the house), healthcare domain is very personal,
thus in general there is only one end-user using a given application

The following figure shows management architecture in the healthcare domain

                Figure 4 : Management architecture for the smart health scenarios
A local configuration manager (e.g., hosted on a mobile portable device such as a smart phone
or hosted on a home gateway) is responsible of configuration of device and application
parameters, as well as providing necessary authorization to remotely access and control end -
user devices and data. A server side management entity is responsible of managing security
and privacy related configurations. It also provides a secure data storage for sensinble
personal data.

    Smart City
BUTLER project particularly interests in user stories from 2 main themes, which are:
      Parking space finder
    Energy monitoring in the city
Concerning device management, these 2 themes have similar requirements that are
summarized in the following table 48.

                 The system shall allow to configure parking      To have a more flexible allocation of the
  SC1Req14                                                                                                    M   Functional
               spaces according to users profile, date and time               parking space

                The system shall automatically integrate new      to discharge the administrators of manual
  SC1Req18                                                                                                    R   Functional
                           parking space sensors                                 configuration

                  The system shall detect and configure the
                                                                    To discharge the user from complex
  SC2Req17      payment devices automatically an integrate it                                                 R   Functional
                                                                           manual configurations
                         seamlessly into the system

                 The system shall remotely monitor the park          To supervise the devices and detect
  SC2Req18                                                                                                    R   Functional
                   meter devices to detect any anomalies                problems as soon as possible

                The system shall automatically integrate new      to discharge the administrators of manual
  SC3Req13                                                                                                    R   Functional
                           parking space sensors                                 configuration

                  The system shall detect energy monitoring
                                                                  to discharge the administrators of manual
  SC4Req20        devices automatically and integrate them                                                    M   Functional
                       seamlessly in the existing system

                The system shall be able to remotely configure     for optimisation or applicaiton specific
  SC4Req21                                                                                                    M   Functional
               the different paramers of the monitoring devices                configurations

                  The system shall detect and configure the
                                                                  to discharge the administrators of manual
   SC6Req7      payment devices automatically an integrate it                                                 M   Functional
                         seamlessly into the system

The identified requirements are mostly related to the easy installation and configuration of
devices in the system. This is indeed an important need in city environements which may
require a large number of devices to be installed; therefore their configuration is not expected
to be done manually. Contrarily to the smart home domain and in healthcare, where the IoT
devices are personal, in city scenarios, the devices serve many end-users at a time. Besides,
cities are large ecosystems in which many stakeholders, from city authorities to utility
companies, are implied.
Therefore, in order to avoid each types of devices having its own management mechanism, it
would be useful to have a common framework that would provide one-stop management
platform that would allow discovering, monitoring and configuring IoT devices in the city
environment. Following figure illustrates such mechanism in the city domain.
                                                                                                                                                     Utility Provider

                                                                                  Auto-discovery and remote monitoring of devices
                Installation of
                 new devices

                                                                                                                                                      Parking Service
                Energy Monitoring devices


                                                                                                                                         Payment Devices
         Installation of                                                                                                                    Provider
          new devices

                       Figure 5 : Management architecture for the smart city scenarios

In this scenario installation of new devices in the city environment would not require complex
on the field configurations, but rather only simple deployment by the installators and the
system would do the discovery and configuration itself within its management servers.

      Smart Transport
Among the Smart Transport scenarios, the user notification on bus arrivals scenario represent
a very good example of a need for a management mechanIsm in a horizontal way inc luding
smart home and smart transport domains. Following requirements have been identified in his
table 49 bellow for his
                   The system shall change calculation
                                                                To keep on                                                            Functional
    ST1Req2       method of the bus location according to                         M                                                                      Task 3.3   CEA
                                                             providing service                                                       Requirement
                        unavailable data sources

                   The system shall trigger the alarm by                                                                              Functional
    ST1Req8                                                           -           M                                                                      Task 3.3   ALBLF
                     activating the connected objects                                                                                Requirement
                  The system shall disable the alarm when                                                                             Functional
    ST1Req9                                                           -           M                                                                      Task 3.3   ALBLF
                          the user leaves the place                                                                                  Requirement
                  The system shall provide an interface to    prefered station,                                                     Non-Functional
    ST1Req13                                                                      M                                                                      Task 3.3   ALBLF
                    set the alarm with user preferences       prefered bus, …                                                        Requirement

                                                             to decide on which
                  The system shall detect any device that                                                                             Functional
    ST1Req23                                                  device to use for   M                                                                      Task 3.3   CEA
                         can give the notification                                                                                   Requirement

The scenario is about notifying the user at home with any object that could be used for this
purpose (e.g., lamp). From the home point of view, in principle the scenario reflects a special
case of a remote management in home networks by third parties that was presented above.
The following figure illustrates the architecture of the system executing such scenario. The
local management system detects the device and understands that it is a device that can be
used for notification thanks to its device descriptions. This information is then sent to third
parties interested in knowing the arrival of such a device, so that they can offer new services
using that device. In this cae, the transportation company detects that the device is at home
and it proposes to the user (via the local management console) that a new bus notification
application is available and it can use the lamp for the notification function.

                 Figure 6: Management architecture for the smart transport scenarios

   Smart Shopping
Smart Shopping scenarios mainly consist of creating interesting deals and notifying the
interested customers of these deals. Following requirements (table 50) have been identified
for that scenario:

          The system must allow retailer to cancel existing
          sparkdeal. When deal is cancelled, those consumers
          how accepted the deal, but did not use the deal, will The retailer must be able to
SS1Req4   be notified.                                          cancel sparkdeals.           M   Functional   Task 3.3   Cascard

                                                             Retailers need to be able to
          The system shall expose an interface to create and add and maintain their store
          modify user account for retailers and their store related information in the
SS1Req1   related information.                               system.                      M      Functional   Task 3.3   Cascard
           The system shall expose an interface to create and Consumers need to be able
           modify user account for consumers and their to maintain their shopping
           consumer      profile     related      information. related information in the
SS1Req2                                                        system.                    M       Functional   Task 3.3   Cascard

           The system shall expose an interface to create a new
           sparkdeal. The sparkdeal is composed of the deal
           content (text, pics, discount information, etc) and the
           matching criteria (consumer profile, location, time of
           the      day,       maximum        receivers,      etc.)

           NOTE: the sparkdeal content and matching criteria is The retailer can invite
SS1Req3    expected to evolve during the work.                  customers in to the shop M        Functional   Task 3.3   Cascard

           The system shall allow the consumer user to enter
           visibility rules to restrict his consumer profile User must maintain control
SS1Req5    information visibility to the sparkdeal service   of the privacy.            M         Functional   Task 3.3   Cascard

                                                              Retailers need to be able to
           The system shall expose an interface to create and add and maintain their store
           modify user account for retailers and their store related information in the
SS1Req1    related information.                               system.                      M      Functional   Task 3.3   Cascard
                                                                To speedup the sparkdeal
                                                                creation process and react in
                                                                real-time to the dynamic
           The system shall be able to create automatically the nature of the request-
SS1Req11   sparkdeals based on predefined rules                 response model                R   Functional   Task 3.3   CEA

The retailer should have a management console that would let him/her to create new
sparkdeals, modify or delete the existing ones and to publish this information in the system.
Besides manual execution of these actions, their automatic excution should be supported in
order to react in real-time to the dynamic demands. This can be performed based on high-level
rules that are predefined. Based on the events captured in the system (e.g., the number of sold
for an item has overpassed a given threshold) the deals can be created automatically (e.g.,
create a 15% of sold for those items).

On the other hand, the user (shopper) also needs to perform some management operations
such as entering his/her profile information, configuring the privacy settings, etc. The
following figure illustrates the management architecture for such scenario
               Figure 7: Management architecture for the smart shopping scenarios

  Generic management architecture
Based on the requirements and the scenario specific architectures presented above, this
section identifies a common management architecture that aims at responding all the specific
requirements. The following Figure illustrates a general architecture that will cover the
BUTLER needs in terms of management. For lisibility reasons we omit to add arrows betweent
the modules, however it is clear that there are strong interactions between these modules that
will be describerd in the following text.

The management mechanism is placed between two main actors:
      Managing entities are actors such as users, applications, manufacturers, service
      Managed entities are devices such as sensors, actuators, home appliances and services
       on top fo these devices.

Between these two classes of entities comes the management middle layer that is composed
of the following modules.
                               users, applications, manufacturers,
                                      service providers, etc.

                                 Management Request Handler
                                                                               Device discovery
                                                                               Device directory
Notification Handler                      Event manager                        Device description
                                          Event processing                     Device resolution
Notifications from devices
                                          Event model                          Device/service mapping
Notifications from providers

    Performance manager                   Software manager               Configuration manager
    monitor performance                   Install, update, start, stop   getParameter, setParameter,
    diagnostics                                                          saveConfig, loadConfig

                               sensors, actuators, appliances, etc.

                 Figure 8 : General Management architecture covering BUTLER scenarios

 Management Request Handler
 This is the entry point to the management subsystem. The requests are received here and
 dispoatched to the correspoing entitites. Typical requests are monitoring a given devic e,
 subscribing to some particular events such as arrival of a device of a given type, performing
 software updates, or loading configurations to devices.

 Notification Handler
 This is a bi-directional information notification module, which at a time:
          notifies the managing entities of events occurring in the system and/or at
           individual devices (new devices discovered, configuration changed, device
           rebbooted, etc.)
       notifies the managed entities of the events occuring at the provider side (e.g., new
        update available, new policies required, etc.)
 The module maintains a subscribers list that contains the entities to notify in case of
 detection of given events.

 Event Manager
 This is the module where the events are detected from the managed entities, processed
 and transferred to the notification handler that transfers the events to the managing
 entities. The system provides the events based on a common event model that is
 comprehensible by the managing entities. Event processing can vary from simple events
 (e.g., binary values, filters) to more complex ones (e.g., temporal correlations).
   Device Discovery
   This module provides a discovery mechanism that is used to detect new devices coming or
   old ones leaving the system. Many existing device communication protocols provide their
   own discovery mechanisms that can be reused for this purpose. After discovery, the device
   should be represented as a BUTLER device that can be detected and used by other BUTLER
   devices or services. The BUTLER device model should thus. Section 5.4 gives more details
   on different information models used for this purpose.
   Software Manager
   This module is responsible of performing software related actions in the system, for
   instance, firmware updates, software patches, application modules can be
   installed/updated/uninstalled with this module.
   Configuration Manager
   This module typically reads and writes device and service parameters. It can save some
   configuration for further loading, as well as reseting the configuration to factory setup.
   Performance Manager
   This module is in charge of monitoring the performance of the devices. It provides means
   of continuously monitoring device and service parameters, as well as performing some
   diagnostic operations on the devices such as ping, reboot or test.

These generic modules would respond to most, if not all, of the requirements mentioned
above in this section. In order to perform the generic management actions, we identify four
generic actions which are: get, set, act and notify:
   - the get operation is used to retrieve values of device parameters.
   - the set operation updates “modifiable” parameter values.
   - the act operation executes common operations such as install, reboot or ping, as well
       as device specific operations.
   - the notify operation is used to subscribe for events such as parameter changed,
       software updated, device arrived, etc.

The operations should be performed on a common management information model such as
the one presented in the section Section 5.4.3.

       1.1.2. Management information models

BUTLER management model will be based on a hierarchical data model that defines the
structure of the management data, identifies some common parameters and defines their
names and attributes. We classify the following parameter families according to the functional
area they belong to:
    - General information containing parameters such as device name, manufacturer, mod el,
        type, location and description.
    - Network related parameters, including network, system, application or physical device
        parameters such as neighbour table, logical address, alarm threshold, supported
        protocols and/or algorithms, sampling rate.
    - System related parameters including energy level, CPU and memory usage, firmware
        version, etc.
    - Device/Vendor specific parameters
      - And operations that the devices can perform, for instance for software deployment and
        lifecycle management. E.g., monolithic firmware upgrade, virtual machine update,
        install/uninstall software modules, application provisioning, radio tests, calibration,
        reboot and factory reset.
The following table gives an example of such a model, with some concrete examples from two
sensor platforms, namely Zolertia 1 based on ContikiOS and Waspmote 2 based on the Zigbee
technology (Table 55 bellow).

Class of parameters       Parameters           Attributs           Example Zolertia      Example Waspmote
                                               Ex :                Ex :                  Manufacturer=
                                               Description         Manufacturer=Zole     waspmote
                                               ="brief             rtia                  Model = Zigbee PRO
                                               decsritpion",       Model =
                                               Type = string       Location = “Room1”

General information       Name
                          Manufacturer                             « Zolertia »          « LIBELIUM »
                          Model                                    « Z1 platform »       « Waspmote »
                          Location             writable=true       « B5D1 »              « B5G1 »
                          Owner                                    « cea »               « cea »

Network         related   Address Type                             aaaa::C30C:0:0:2      0013A200407691D7
parameters                Packets sent
                          Uptime                                   “00:00:03:25”         “00:00:03:25”
                          RSSI                                     « 78 »                « 78 »
                          Routing parent                           « aaaa::C30C:0:0:2    « C5F5 »

System          related   OSversion            Writable        =   “Contiki 2.6”         “prog002”
parameters                                     (Zolertia: false,
                          Samling Rate
Device/Vendor specific                       Zolertia.ContikiOSV   Waspmote.ZigbeeVer
parameters                                                         ersion                sion

Operations                getDataModel                             admin/reboot,         sleep
                          saveConfig                               admin/sleep

For an extensibility support, the structure of the data model is hierarchical. A root node is
followed by the parameter family nodes which are then followed by parameter groups. A
parameter group can recursively embed other parameter groups. A special parameter group is
an array parameter group containing different instances of the same parameter group, having
thus the same data structure. Leaf nodes finally contain the actual values of parameters. An
absolute path defines the route from the root node to a leaf node, therefore defines the actual
name of a parameter.

Each family contains a set of common parameters. These parameters are intended to give an
overview of the available devices and provide a minimum management facility. Since for
instance sensors are autonomous, a sensor may not support a given common parameter or
operation. In this case, the value of the unsupported parameter is null and the unsupported
method has no effect on the sensor. Each sensor device may also support some additional
vendor specific management parameters and operations. These parameters can be included in
the data model with the special group name SpecificExtension under any parameter group .
Each parameter has additional attributes defining its characteristics such as type, description,
writability and notifiability.

The following gives the grammar defining the absolute paths of the data model:

Root = "/"

Seperator = "."

Family = "General" | "Network" | "System" | "Vendor" | "Operations" Seperator

NodeName = [A-Za-z0-9n!#%$’&()@_/gf*+?,:;=-]+

ParameterGroup = NodeName Seperator

ParameterGroupInstance = NodeName "[" [0-9]+ "]" Seperator

Leaf = NodeName

Path = Root Family [ParameterGroup | ParameterGroupInstance]*

AbsolutePath = Path Leaf

Below is an example of an absolute path for the sampling rate parameter:

Sensor.System.SamplingRate {
description = ‘the sampling rate of the sensor in milliseconds’
type = integer
writable = true
notifiable = true
The description attribute gives brief information about the parameter. Type attribute defines
the type of the parameter, which can be one of the following: string, integer, long, double,
date, boolean; or a list of one of these types. The writable attribute specifies whether the
parameter is read-only. Finally, the notifiable attribute specifies whether the modification of
the value of the parameter can trigger a notification for interested subscribers.

The model also contains a list of operations that can be performed on the sensors. They are
listed under the special parameter group Operations. Each operation has also attributes
defining its input and output parameters. Operations either directly modify the data (e.g., via
set method) or trigger an action on the sensor which can indirectly modifies the data (e.g.,
software install). The following section presents the management operations that can be
performed on the sensors

This data model aims at being generic to reflect any management operation to be performed
on devices. Extensions will be done during the following years of the project to reflect the
requirements that will appear with new applications and new types of devices.


[NetConf] Network Configuration,

[WBEM] Web Based Enterprise Management.

[WSDM] Web Services Distributed         Management.
home.php?wg abbrev=wsdm.
[BBF] Broadband Forum. TR-069, CPE WAN Management Protocol v1.1.

[UPnP-DM] Universal Plug&Play Device Management, White Paper, April 2011.

[OMA-DM]      Open     Mobile      Alliance    Device       Management       Working      Group.

[M2M]    ETSI     M2M,      Machine     to  machine        communications      working    group.

[Ruiz03] L. B. Ruiz, J. M. Nogueira, and A. A. F. Loureiro, “Manna: a management architecture for
wireless sensor networks,” Communications Magazine, IEEE, vol. 41, no. 2, pp. 116–125, 2003.

[Shen03] C. chung Shen, C. Jaikaeo, C. Srisathapornphat, and Z. Huang, “An adaptive management
architecture for ad hoc networks,” IEEE Communications Magazine, vol. 41, pp. 108–115, 2003.

[Cerpa04] A. Cerpa and D. Estrin, “Ascent: Adaptive self-configuring sensor networks topologies,”
IEEE Transactions on Mobile Computing, vol. 3, no. 3, pp. 272–285, 2004.

[Al-Karaki04] J. N. Al-Karaki and A. E. Kamal, “Routing techniques in wireless sensor networks: a
survey,” IEEE Wireless Communications, vol. 11, no. 6, pp. 6–28, 2004.
[Marrn05] P. J. Marrn, A. Lachenmann, D. Minder, M. Gauger, O. Saukh, and K. Rothermel,
“Management and configuration issues for sensor networks,” Int Journal of Network Management,
vol. 15, pp. 235–253, 2005.

[Stathopoulos03] T. Stathopoulos, J. Heidemann, and D. Estrin, “A remote code update mechanism
for wireless sensor networks,” Los Angeles, CA, USA, Tech. Rep. 30, 2003.

[Sugihara08] R. Sugihara and R. K. Gupta, “Programming models for sensor networks: a survey,” ACM
Transactions on Sensor Networks, vol. 4, no. 2, pp. 1–29, March 2008.

[Kogekar04] S. Kogekar, S. Neema, B. Eames, X. Koutsoukos, A. Ledeczi, and M. Maroti, “Constraint-
guided dynamic reconfiguration in sensor networks,” in IPSN ’04:Proceedings of the 3rd international
symposium on Information processing in sensor networks. ACM, 2004, pp. 379–387.
[Bae06] J.-H. Bae, K.-O. Lee, and Y.-Y. Park, “Moneta: an embedded monitoring system for ubiquitous
network environments,” Consumer Electronics, IEEE Transactions on, vol. 52, no. 2, pp. 414–420,
May 2006.

[Levis02] P. Levis and D. Culler, “Maté: a tiny virtual machine for sensor networks,” in ASPLOS-X:
Proceedings of the 10th international conference on Architectural support for programming
languages and operating systems. New York, NY, USA: ACM, 2002, pp. 85–95.
[Liu03] T. Liu and M. Martonosi, “Impala: A middleware system for managing autonomic, parallel
sensor systems,” in In PPoPP 03: Proceedings of the 9th ACM SIGPLAN symposium on Principles and
practice of parallel programming. ACM Press, 2003, pp. 107–118.

[Madden05] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TinyDB: an acquisitional
query processing system for sensor networks,” ACM Trans. Database Syst., vol. 30, no. 1, pp. 122–
173, 2005.

[Fok05] C.-L. Fok, G.-C. Roman, and C. Lu, “Rapid development and flexible deployment of adaptive
wireless sensor network applications,” in Proceedings of the 25th IEEE International Conference on
Distributed Computing Systems. Washington, DC, USA: IEEE, 2005, pp. 653–662.

[SunSPOT]   Sun SPOT Project.

[MICA] MICA motes.

[COMAN]         Management          of     Constrained          Networks         and       Devices,

Shared By: