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 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
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, audiovisual 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, multimanufacturer 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 manageragent 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
To ensure content is still available after the
ressources (content, tuner, bandwidth)
move
for a given user
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, 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.
1.2.3.1.1. Local monitoring and configuration of devices by end-users
MA
MA
MA
MA
MA
MA
Management
Agent (MA)
Home
gateway
Local
management
server
end-user
Management
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.
1.2.3.1.2. Remote monitoring and configuration of devices/service by
third parties
MA
MA
MA
MA
MA
MA
Management
Agent (MA)
end-user
Home gateway
Local
management
server
Management
console
Internet
Service
provider
management
server
Telecom
operator
management
server
Manufacturer
management
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
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.
1.2.3.2. 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:
SHC1Req16
The system shall allow authorized to allow for instance
entities
to
update doctors to provide more
recommendations
precise recommendations
M
Functional
Task 3.3
CEA
SHC1Req17
The system shall discover and
configure
health
devices
automatically
with
minimum to discharge the user from
intervention required by the user
complex configurations
M
Functional
Task 3.3
CEA
SHC2Req4
The system shall allow the doctor
to remotely control the camera To empower the doctor for
and microphone of the user
efficient system utilization
M
Functional
Task 3.3
KU Leuven
SHC3Req12
The system shall let to the users
and/or caregivers to configure To adapt to the evolution
reminding periods
of the patient
R
Functional
Task 3.3
CEA
SHC4Req9
The system shall let users to
configure
the
application
parameters (enabling localisation
information, list of contact to give the control to the
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.
1.2.3.3. 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.
SC1Req14
The system shall allow to configure parking
spaces according to users profile, date and time
To have a more flexible allocation of the
parking space
M
Functional
SC1Req18
The system shall automatically integrate new
parking space sensors
to discharge the administrators of manual
configuration
R
Functional
SC2Req17
The system shall detect and configure the
payment devices automatically an integrate it
seamlessly into the system
To discharge the user from complex
manual configurations
R
Functional
SC2Req18
The system shall remotely monitor the park
meter devices to detect any anomalies
To supervise the devices and detect
problems as soon as possible
R
Functional
SC3Req13
The system shall automatically integrate new
parking space sensors
to discharge the administrators of manual
configuration
R
Functional
SC4Req20
The system shall detect energy monitoring
devices automatically and integrate them
seamlessly in the existing system
to discharge the administrators of manual
configuration
M
Functional
SC4Req21
The system shall be able to remotely configure
the different paramers of the monitoring devices
for optimisation or applicaiton specific
configurations
M
Functional
SC6Req7
The system shall detect and configure the
payment devices automatically an integrate it
seamlessly into the system
to discharge the administrators of manual
configuration
M
Functional
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
Gateways
and
repeaters
Installation of
new devices
Energy Monitoring devices
Gateways
and
repeaters
Installation of
new devices
Parking Service
Provider
Payment Devices
Provider
Payment
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.
1.2.3.4. 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
ST1Req2
The system shall change calculation
method of the bus location according to
unavailable data sources
To keep on
providing service
M
Functional
Requirement
Task 3.3
CEA
ST1Req8
The system shall trigger the alarm by
activating the connected objects
-
M
Functional
Requirement
Task 3.3
ALBLF
ST1Req9
The system shall disable the alarm when
the user leaves the place
-
M
Functional
Requirement
Task 3.3
ALBLF
ST1Req13
The system shall provide an interface to
set the alarm with user preferences
prefered station,
prefered bus, …
M
Non-Functional
Requirement
Task 3.3
ALBLF
ST1Req23
The system shall detect any device that
can give the notification
to decide on which
device to use for
notification
M
Functional
Requirement
Task 3.3
CEA
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
1.2.3.5. 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:
SS1Req4
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
be notified.
cancel sparkdeals.
M
Functional
Task 3.3
Cascard
SS1Req1
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
related information.
system.
M
Functional
Task 3.3
Cascard
SS1Req2
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
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.)
SS1Req3
NOTE: the sparkdeal content and matching criteria is The retailer can invite
expected to evolve during the work.
customers in to the shop
M
Functional
Task 3.3
Cascard
SS1Req5
The system shall allow the consumer user to enter
visibility rules to restrict his consumer profile User must maintain control
information visibility to the sparkdeal service
of the privacy.
M
Functional
Task 3.3
Cascard
SS1Req1
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
related information.
system.
M
Functional
Task 3.3
Cascard
SS1Req11
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 requestsparkdeals 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
1.2.3.6. 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
providers

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
Event processing
Event model
Notifications from devices
Notifications from providers
Performance manager
monitor performance
diagnostics
Device directory
Device description
Device resolution
Device/service mapping
Event manager
Notification Handler
Software manager
Install, update, start, stop
Configuration manager
getParameter, setParameter,
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
General information
Name
Manufacturer
Description
Model
Location
Owner
Network
parameters
System
parameters
related
related
Device/Vendor specific
parameters
Operations
1
2
www.zolertia.com
www.libelium.com
Attributs
Ex :
Description
="brief
decsritpion",
Type = string
Writable=false
Notifiable=true
writable=true
Address Type
Packets sent
Uptime
RSSI
Routing parent
OSversion
Energylevel
CpuUsage
Freememory
Samling Rate
DeviceSpecific.xxx
getDataModel
saveConfig
loadConfig
resetConfig
ping
reboot
stop(TaskId)
Writable
=
(Zolertia: false,
Waspmote:
true)
Example Zolertia
Ex :
Manufacturer=Zole
rtia
Model =
Location = “Room1”
Example Waspmote
Manufacturer=
waspmote
Model = Zigbee PRO
« Zolertia »
« LIBELIUM »
« Z1 platform »
« B5D1 »
« cea »
« Waspmote »
« B5G1 »
« cea »
aaaa::C30C:0:0:2
0013A200407691D7
“00:00:03:25”
« 78 »
« aaaa::C30C:0:0:2
»
“00:00:03:25”
« 78 »
« C5F5 »
“Contiki 2.6”
“prog002”
Zolertia.ContikiOSV
ersion
Waspmote.ZigbeeVer
sion
admin/reboot,
admin/sleep
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.
References
[NetConf] Network Configuration, http://www.ietf.org/html.charters/netconfcharter.html
[WBEM] Web Based Enterprise Management. http://www.dmtf.org/standards/wbem/.
[WSDM] Web Services Distributed
home.php?wg abbrev=wsdm.
Management.
http://www.oasisopen.org/committees/tc
[BBF] Broadband Forum. TR-069, CPE WAN Management Protocol v1.1.
[UPnP-DM] Universal Plug&Play Device Management, White Paper, April 2011.
http://upnp.org/resources/whitepapers/UPnP%20Device%20Management%20White%20Paper_201
1.pdf
[OMA-DM]
Open
Mobile
Alliance
Device
http://www.openmobilealliance.org/technical/DM.aspx
Management
[M2M]
ETSI
M2M,
Machine
to
machine
http://www.etsi.org/website/technologies/m2m.aspx
communications
Working
working
Group.
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, “Constraintguided 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. http://www.sunspotworld.com/
[MICA] MICA motes. http://www.xbow.com/Products/wproductsoverview.aspx
[COMAN]
Management
of
Constrained
https://www.ietf.org/mailman/listinfo/coma
Networks
and
Devices,